Design Patterns

Contents

1 Overview 1
1.1 Design pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.2 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.3 Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.5 Classification and list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.6 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.7 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.10 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Creational Patterns 6
2.1 Creational pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Abstract factory pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.5 C# example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.6 Java example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.7 PHP example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.8 Crystal example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.9 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

i
ii CONTENTS

2.3 Builder pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Advantages[3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
[3]
2.3.3 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Factory method pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.3 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Lazy initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.1 The “lazy factory” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Multiton pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.3 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Object pool pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.4 Handling of empty pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.5 Pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.6 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.7.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8 Prototype pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
CONTENTS iii

2.8.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.2 Rules of thumb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8.3 Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.4 C# Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.5 Java Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.6 PHP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8.9 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.9 Resource Acquisition Is Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.1 C++11 example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.3 Typical uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9.4 Clang and GCC “cleanup” extension for C . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9.6 Reference counting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.9.8 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9.9 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Singleton pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10.1 Common uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10.3 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.10.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.10.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Structural patterns 29
3.1 Structural pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Adapter pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3 Bridge pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
iv CONTENTS

3.4 Composite pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 When to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.4 Variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Decorator pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.1 Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Facade pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 Front Controller pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.1 Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.4 Benefits and liabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.5 Relationship with MVC pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.6 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.9 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.7.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8 Flyweight pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.2 Immutability and equality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.3 Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.4 Example in C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.5 Example in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.6 Example in Scala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
CONTENTS v

3.8.7 Example in Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.8 Example in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8.9 Example in Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8.10 Example in Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.8.11 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.8.12 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9 Proxy pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.1 Possible Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.9.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.9.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.9.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.9.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4 Behavioral patterns 51
4.1 Behavioral pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Chain-of-responsibility pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2.2 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Command pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.1 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4 Interpreter pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.1 Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.4.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Iterator pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5.2 Language-specific implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
vi CONTENTS

4.6 Mediator pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6.2 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.6.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7 Memento pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7.1 Java example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.7.2 C# Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.7.3 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8 Null Object pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.8.4 Relation to other patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.8.5 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.8.6 In various languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.8.7 Criticism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8.8 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.8.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9 Observer pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9.1 Strong vs. Weak reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9.2 Coupling and typical pub-sub implementations . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.9.5 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.9.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.9.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10 Publish/subscribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10.1 Message filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.10.2 Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.10.3 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.10.4 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.10.5 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.10.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.10.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.10.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.11 Design pattern Servant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.11.1 Description and simple example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CONTENTS vii

4.11.2 Two ways of implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.11.3 How to implement Servant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.11.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.11.5 Similar design pattern: Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.11.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.11.7 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.12 Specification pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.12.1 Code examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.12.2 Example of use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.12.3 Criticisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.12.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.12.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.13 State pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.13.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.13.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.13.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.13.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.13.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.14 Strategy pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.14.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.14.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.14.3 Strategy and open/closed principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.14.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.14.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.14.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.15 Template method pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.15.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.15.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.15.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.15.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.15.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.15.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.16 Visitor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.16.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.16.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.16.3 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.16.4 C# example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.16.5 C++ example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.16.6 Java example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.16.7 Common Lisp example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.16.8 Related design patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
viii CONTENTS

4.16.9 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.16.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.16.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5 Concurrency patterns 88
5.1 Concurrency pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.1 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.1.3 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2 Active object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.2 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.4 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Balking pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 Messaging pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.1 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.2 ØMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5 Double-checked locking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.1 Usage in C++11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.2 Usage in Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.5.3 Usage in Microsoft .NET (Visual Basic, C#) . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.5.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.5.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.5.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.6 Asynchronous method invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.2 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.6.4 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7 Guarded suspension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.7.4 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
CONTENTS ix

5.7.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.8 Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.8.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.8.2 Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.8.3 Database locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.8.4 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.8.5 Language support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.8.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.8.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.8.8 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.9 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.9.1 Mutual exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.9.2 Condition variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.9.3 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.9.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.9.5 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.9.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.9.7 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.10 Reactor pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.10.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.10.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.10.3 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.10.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.10.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.11 Readers-writer lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.11.1 Upgradable RW lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.11.2 Priority policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.11.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.11.4 Programming language support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.11.5 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.11.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.11.7 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.11.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.12 Scheduler pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.12.1 Types of operating system schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.12.2 Scheduling disciplines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.12.3 Operating system process scheduler implementations . . . . . . . . . . . . . . . . . . . . . 118
5.12.4 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.12.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.12.6 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.13 Thread pool pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
x CONTENTS

5.13.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5.13.2 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.13.3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.13.4 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.14 Thread-local storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.14.1 Windows implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.14.2 Pthreads implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.14.3 Language-specific implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.14.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.14.5 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6 Text and image sources, contributors, and licenses 127

6.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.3 Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Chapter 1

Overview

1.1 Design pattern the definition of building blocks to support task syn-
chronization.
In software engineering, a software design pattern is a
Implementation strategy patterns Addressing con-
general reusable solution to a commonly occurring prob-
cerns related to implementing source code to
lem within a given context in software design. It is not
support
a finished design that can be transformed directly into
source or machine code. It is a description or template for 1. program organization, and
how to solve a problem that can be used in many different
situations. Design patterns are formalized best practices 2. the common data structures specific to parallel
that the programmer can use to solve common problems programming.
when designing an application or system.
Structural design patterns Addressing concerns re-
Object-oriented design patterns typically show relation- lated to global structures of applications being de-
ships and interactions between classes or objects, without veloped.
specifying the final application classes or objects that are
involved. Patterns that imply mutable state may be un-
suited for functional programming languages, some pat- 1.1.2 History
terns can be rendered unnecessary in languages that have
built-in support for solving the problem they are trying Patterns originated as an architectural concept by
to solve, and object-oriented patterns are not necessarily Christopher Alexander (1977/79). In 1987, Kent Beck
suitable for non-object-oriented languages. and Ward Cunningham began experimenting with the
Design patterns may be viewed as a structured approach idea of applying patterns to programming – specifi-
to computer programming intermediate between the lev- cally pattern languages – and presented their results at
[6][7]
els of a programming paradigm and a concrete algorithm. the OOPSLA conference that year. In the following
years, Beck, Cunningham and others followed up on this
work.
1.1.1 Types
Design patterns gained popularity in computer science
after the book Design Patterns: Elements of Reusable
Design patterns reside in the domain of modules and in-
Object-Oriented Software was published in 1994 by the so-
terconnections. At a higher level there are architectural
called “Gang of Four” (Gamma et al.), which is frequently
patterns which are larger in scope, usually describing an
abbreviated as “GoF”. That same year, the first Pattern
overall pattern followed by an entire system.[1]
Languages of Programming Conference was held and the
There are many types of design patterns, for instance [2] following year, the Portland Pattern Repository was set up
[3]
for documentation of design patterns. The scope of the
term remains a matter of dispute. Notable books in the
Algorithm strategy patterns Addressing concerns re- design pattern genre include:
lated to high-level strategies describing how to ex-
ploit application characteristics on a computing plat- • Gamma, Erich; Helm, Richard; Johnson, Ralph;
form. Vlissides, John (1995). Design Patterns: Elements
Computational design patterns Addressing concerns of Reusable Object-Oriented Software. Addison-
related to key computation identification.[4][5] Wesley. ISBN 0-201-63361-2.

Execution patterns Which address issues related to • Brinch Hansen, Per (1995). Studies in Computa-
lower-level support of application execution, includ- tional Science: Parallel Programming Paradigms.
ing strategies for executing streams of tasks and for Prentice Hall. ISBN 0-13-439324-4.

1
2 CHAPTER 1. OVERVIEW

• Buschmann, Frank; Meunier, Regine; Rohnert, the Structure, Participants, and Collaboration sections.
Hans; Sommerlad, Peter (1996). Pattern-Oriented These sections describe a design motif: a prototypi-
Software Architecture, Volume 1: A System of Pat- cal micro-architecture that developers copy and adapt to
terns. John Wiley & Sons. ISBN 0-471-95869-7. their particular designs to solve the recurrent problem de-
scribed by the design pattern. A micro-architecture is
• Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans;
a set of program constituents (e.g., classes, methods...)
Buschmann, Frank (2000). Pattern-Oriented Soft-
and their relationships. Developers use the design pattern
ware Architecture, Volume 2: Patterns for Concur-
by introducing in their designs this prototypical micro-
rent and Networked Objects. John Wiley & Sons.
architecture, which means that micro-architectures in
ISBN 0-471-60695-2.
their designs will have structure and organization similar
• Fowler, Martin (2002). Patterns of Enterprise Appli- to the chosen design motif.
cation Architecture. Addison-Wesley. ISBN 978-0-
321-12742-6.
Domain-specific patterns
• Hohpe, Gregor; Woolf, Bobby (2003). Enterprise
Integration Patterns: Designing, Building, and De- Efforts have also been made to codify design patterns in
ploying Messaging Solutions. Addison-Wesley. particular domains, including use of existing design pat-
ISBN 0-321-20068-3. terns as well as domain specific design patterns. Exam-
• Freeman, Eric T; Robson, Elisabeth; Bates, Bert; ples include user interface design patterns,[11] information
[12] [13]
Sierra, Kathy (2004). Head First Design Patterns. visualization,[15] secure design, “secure usability”,[14]
O'Reilly Media. ISBN 0-596-00712-4. Web design and business model design.[16]
The annual Pattern Languages of Programming Confer-
Although design patterns have been applied practically ence proceedings [17] include many examples of domain-
for a long time, formalization of the concept of design specific patterns.
patterns languished for several years.[8]

1.1.5 Classification and list

1.1.3 Practice
Design patterns were originally grouped into the cat-
Design patterns can speed up the development process by egories: creational patterns, structural patterns, and
providing tested, proven development paradigms.[9] Ef- behavioral patterns, and described using the concepts
fective software design requires considering issues that of delegation, aggregation, and consultation. For fur-
may not become visible until later in the implementa- ther background on object-oriented design, see coupling
tion. Reusing design patterns helps to prevent subtle is- and cohesion, inheritance, interface, and polymorphism.
sues that can cause major problems, and it also improves Another classification has also introduced the notion of
code readability for coders and architects who are famil- architectural design pattern that may be applied at the ar-
iar with the patterns. chitecture level of the software such as the Model–View–
In order to achieve flexibility, design patterns usually in- Controller pattern.
troduce additional levels of indirection, which in some
cases may complicate the resulting designs and hurt ap-
Creational patterns
plication performance.
By definition, a pattern must be programmed anew into Structural patterns
each application that uses it. Since some authors see this
as a step backward from software reuse as provided by Behavioral patterns
components, researchers have worked to turn patterns
into components. Meyer and Arnout were able to pro- Concurrency patterns
vide full or partial componentization of two-thirds of the
patterns they attempted.[10] 1.1.6 Documentation
Software design techniques are difficult to apply to a
broader range of problems. Design patterns provide gen- The documentation for a design pattern describes the con-
eral solutions, documented in a format that does not re- text in which the pattern is used, the forces within the
quire specifics tied to a particular problem. context that the pattern seeks to resolve, and the sug-
gested solution.[28] There is no single, standard format for
documenting design patterns. Rather, a variety of dif-
1.1.4 Structure ferent formats have been used by different pattern au-
thors. However, according to Martin Fowler, certain
Design patterns are composed of several sections (see pattern forms have become more well-known than oth-
§ Documentation below). Of particular interest are ers, and consequently become common starting points for
1.1. DESIGN PATTERN 3

new pattern-writing efforts.[29] One example of a com- and showed that code-level dependencies were removed
monly used documentation format is the one used by from the implementations of 17 of the 23 design patterns
Erich Gamma, Richard Helm, Ralph Johnson and John and that aspect-oriented programming could simplify the
Vlissides (collectively known as the “Gang of Four”, or implementations of design patterns.[31] See also Paul Gra-
GoF for short) in their book Design Patterns. It contains ham’s essay “Revenge of the Nerds”.[32]
the following sections: Moreover, inappropriate use of patterns may unnecessar-
ily increase complexity.[33]
• Pattern Name and Classification: A descriptive
and unique name that helps in identifying and refer-
ring to the pattern. 1.1.8 See also
• Intent: A description of the goal behind the pattern • Abstraction principle
and the reason for using it.
• Algorithmic skeleton
• Also Known As: Other names for the pattern.
• Anti-pattern
• Motivation (Forces): A scenario consisting of a
problem and a context in which this pattern can be • Architectural pattern
used.
• Debugging patterns
• Applicability: Situations in which this pattern is us-
able; the context for the pattern. • Design pattern
• Structure: A graphical representation of the pat- • Distributed design patterns
tern. Class diagrams and Interaction diagrams may
be used for this purpose. • Double-chance function

• Participants: A listing of the classes and objects • Enterprise Architecture framework

used in the pattern and their roles in the design. • GRASP (object-oriented design)
• Collaboration: A description of how classes and
• Helper class
objects used in the pattern interact with each other.
• Interaction design pattern
• Consequences: A description of the results, side
effects, and trade offs caused by using the pattern. • List of software development philosophies
• Implementation: A description of an implementa- • List of software engineering topics
tion of the pattern; the solution part of the pattern.
• Pattern language
• Sample Code: An illustration of how the pattern
can be used in a programming language. • Pattern theory
• Known Uses: Examples of real usages of the pat- • Pedagogical patterns
tern.
• Portland Pattern Repository
• Related Patterns: Other patterns that have some
relationship with the pattern; discussion of the dif- • Refactoring
ferences between the pattern and similar patterns.
• Software development methodology

1.1.7 Criticism
The concept of design patterns has been criticized in sev- 1.1.9
eral ways.
The design patterns may just be a sign of some miss-
ing features of a given programming language (Java or
C++ for instance). Peter Norvig demonstrates that 16 out
of the 23 patterns in the Design Patterns book (which is
primarily focused on C++) are simplified or eliminated
(via direct language support) in Lisp or Dylan.[30] Re-
lated observations were made by Hannemann and Kicza-
les who implemented several of the 23 design patterns us-
ing an aspect-oriented programming language (AspectJ)
• Material Design
References
[1] Martin, Robert C. (2000). “Design Principles and Design
Patterns” (PDF).
[2] https://sourcemaking.com/design_patterns
[3] https://pmsware.wordpress.com/tag/
computational-design-patterns/
[4] "Category:Computational Thinking Patterns – Scalable
Game Design wiki”. sgd.cs.colorado.edu. Retrieved
2015-12-26.
4 CHAPTER 1. OVERVIEW
[5] “Introduction to Software Engineer-
ing/Architecture/Design Patterns – Wikibooks, open
books for an open world”. en.wikibooks.org. Retrieved
2015-12-26.
[6] Smith, Reid (October 1987). Panel on design method-
ology. OOPSLA '87 Addendum to the Proceedings.
doi:10.1145/62138.62151., “Ward cautioned against re-
quiring too much programming at, what he termed, 'the
high level of wizards.' He pointed out that a written 'pat-
tern language' can significantly improve the selection and
application of abstractions. He proposed a 'radical shift in
the burden of design and implementation' basing the new
methodology on an adaptation of Christopher Alexander’s
work in pattern languages and that programming-oriented
pattern languages developed at Tektronix has significantly
aided their software development efforts.”
[7] Beck, Kent; Cunningham, Ward (September 1987).
Using Pattern Languages for Object-Oriented Program.
OOPSLA '87 workshop on Specification and Design for
Object-Oriented Programming. Retrieved 2006-05-26.
[8] Baroni, Aline Lúcia; Guéhéneuc, Yann-Gaël; Albin-
Amiot, Hervé (June 2003). “Design Patterns Formal-
ization”. Nantes: École Nationale Supérieure des Tech-
niques Industrielles et des Mines de Nantes. CiteSeerX
10.1.1.62.6466 .
[9] Bishop, Judith. “C# 3.0 Design Patterns: Use the Power
of C# 3.0 to Solve Real-World Problems”. C# Books
from O'Reilly Media. Retrieved 2012-05-15. If you want
to speed up the development of your .NET applications,
you're ready for C# design patterns -- elegant, accepted
and proven ways to tackle common programming prob-
lems.
[10] Meyer, Bertrand; Arnout, Karine (July 2006).
“Componentization: The Visitor Example”
(PDF). IEEE Computer. IEEE. 39 (7): 23–30.
doi:10.1109/MC.2006.227.
[11] Laakso, Sari A. (2003-09-16). “Collection of User Inter-
face Design Patterns”. University of Helsinki, Dept. of
Computer Science. Retrieved 2008-01-31.
[12] Heer, J.; Agrawala, M. (2006). “Software Design Pat-
terns for Information Visualization”. IEEE Transactions
on Visualization and Computer Graphics. 12 (5): 853–60.
doi:10.1109/TVCG.2006.178. PMID 17080809.
[13] Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svo-
boda, David; Togashi, Kazuya (2009). Secure Design Pat-
terns (PDF). Software Engineering Institute.
[14] Garfinkel, Simson L. (2005). Design Principles and Pat-
terns for Computer Systems That Are Simultaneously Se-
cure and Usable (Ph.D. thesis).
[15] “Yahoo! Design Pattern Library”. Retrieved 2008-01-31.
[16] “How to design your Business Model as a Lean Startup?".
Retrieved 2010-01-06.
[17] Pattern Languages of Programming, Conference proceed-
ings (annual, 1994—)
[18] McConnell, Steve (June 2004). “Design in Construction”.
Code Complete (2nd ed.). Microsoft Press. p. 104. ISBN
978-0-7356-1967-8. Table 5.1 Popular Design Patterns
[19] “Design Patterns: Dependency injection”. Retrieved
2011-04-13. The use of a factory class is one common
way to implement DI.
[20] Fowler, Martin (2002). Patterns of Enterprise Application
Architecture. Addison-Wesley. ISBN 978-0-321-12742-
6.
[21] C. Martin, Robert (2002). “28. Extension object”. Agile
Software Development, Principles, Patterns, and Practices.
p. 408. ISBN 978-0135974445.
[22] Bloch, Joshua (2008). “Item 37: Use marker interfaces to
define types”. Effective Java (Second edition). Addison-
Wesley. p. 179. ISBN 978-0-321-35668-0.
[23] “Twin – A Design Pattern for Modeling Multiple Inheri-
tance” (PDF).
[24] Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans;
Buschmann, Frank (2000). Pattern-Oriented Software Ar-
chitecture, Volume 2: Patterns for Concurrent and Net-
worked Objects. John Wiley & Sons. ISBN 0-471-60695-
2.
[25] Binding Properties
[26] Nagel, Christian; Evjen, Bill; Glynn, Jay; Watson, Karli;
Skinner, Morgan (2008). “Event-based Asynchronous
Pattern”. Professional C# 2008. Wiley. pp. 570–571.
ISBN 0-470-19137-6.
[27] Lock Pattern
[28] Gabriel, Dick. “A Pattern Definition”. Archived from the
original on 2007-02-09. Retrieved 2007-03-06.
[29] Fowler, Martin (2006-08-01). “Writing Software Pat-
terns”. Retrieved 2007-03-06.
[30] Norvig, Peter (1998). Design Patterns in Dynamic Lan-
guages.
[31] Hannemann, Jan (2002). Design pattern implementation
in Java and AspectJ.
[32] Graham, Paul (2002). Revenge of the Nerds. Retrieved
2012-08-11.
[33] McConnell, Steve (2004). Code Complete: A Practical
Handbook of Software Construction, 2nd Edition. p. 105.
1.1.10 Further reading
• Alexander, Christopher; Ishikawa, Sara; Silverstein,
Murray; Jacobson, Max; Fiksdahl-King, Ingrid; An-
gel, Shlomo (1977). A Pattern Language: Towns,
Buildings, Construction. New York: Oxford Univer-
sity Press. ISBN 978-0-19-501919-3.
• Alur, Deepak; Crupi, John; Malks, Dan (May
2003). Core J2EE Patterns: Best Practices and De-
sign Strategies (2nd Edition). Prentice Hall. ISBN
0-13-142246-4.
1.1. DESIGN PATTERN 5

• Beck, Kent (October 2007). Implementation Pat- • Larman, Craig (2005). Applying UML and Patterns.
terns. Addison-Wesley. ISBN 978-0-321-41309-3. Prentice Hall. ISBN 0-13-148906-2.
• Beck, Kent; Crocker, R.; Meszaros, G.; Coplien, J. • Liskov, Barbara; Guttag, John (2000). Program De-
O.; Dominick, L.; Paulisch, F.; Vlissides, J. (March velopment in Java: Abstraction, Specification, and
1996). Proceedings of the 18th International Con- Object-Oriented Design. Addison-Wesley. ISBN 0-
ference on Software Engineering. pp. 25–30. 201-65768-6.
• Borchers, Jan (2001). A Pattern Approach to Inter- • Manolescu, Dragos; Voelter, Markus; Noble, James
action Design. John Wiley & Sons. ISBN 0-471- (2006). Pattern Languages of Program Design 5.
49828-9. Addison-Wesley. ISBN 0-321-32194-4.
• Coplien, James O.; Schmidt, Douglas C. (1995). • Marinescu, Floyd (2002). EJB Design Patterns: Ad-
Pattern Languages of Program Design. Addison- vanced Patterns, Processes and Idioms. John Wiley
Wesley. ISBN 0-201-60734-4. & Sons. ISBN 0-471-20831-0.
• Coplien, James O.; Vlissides, John M.; Kerth, Nor- • Martin, Robert Cecil; Riehle, Dirk; Buschmann,
man L. (1996). Pattern Languages of Program De- Frank (1997). Pattern Languages of Program De-
sign 2. Addison-Wesley. ISBN 0-201-89527-7. sign 3. Addison-Wesley. ISBN 0-201-31011-2.
• Eloranta, Veli-Pekka; Koskinen, Johannes; Leppä- • Mattson, Timothy G; Sanders, Beverly A.;
nen, Marko; Reijonen, Ville (2014). Designing Dis- Massingill, Berna L. (2005). Patterns for Par-
tributed Control Systems: A Pattern Language Ap- allel Programming. Addison-Wesley. ISBN
proach. Wiley. ISBN 1118694155. 0-321-22811-1.
• Fowler, Martin (1997). Analysis Patterns: Reusable • Shalloway, Alan; Trott, James R. (2001). Design
Object Models. Addison-Wesley. ISBN 0-201- Patterns Explained, Second Edition: A New Perspec-
89542-0. tive on Object-Oriented Design. Addison-Wesley.
• Fowler, Martin (2003). Patterns of Enterprise Appli- ISBN 0-321-24714-0.
cation Architecture. Addison-Wesley. ISBN 978-0- • Vlissides, John M. (1998). Pattern Hatching: De-
321-12742-6. sign Patterns Applied. Addison-Wesley. ISBN 0-
• Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; 201-43293-5.
Bates, Bert (2004). Head First Design Patterns.
• Weir, Charles; Noble, James (2000). Small Memory
O'Reilly Media. ISBN 0-596-00712-4.
Software: Patterns for systems with limited memory.
• Hohmann, Luke; Fowler, Martin; Kawasaki, Guy Addison-Wesley. ISBN 0-201-59607-5. Archived
(2003). Beyond Software Architecture. Addison- from the original on 2007-06-17.
Wesley. ISBN 0-201-77594-8.
• Gabriel, Richard (1996). Patterns of Software: Tales
From The Software Community (PDF). Oxford Uni-
versity Press. p. 235. ISBN 0-19-512123-6.
Archived from the original (PDF) on 2003-08-01.
• Gamma, Erich; Helm, Richard; Johnson, Ralph;
Vlissides, John (1995). Design Patterns: Elements
of Reusable Object-Oriented Software. Addison-
Wesley. ISBN 0-201-63361-2.
• Hohpe, Gregor; Woolf, Bobby (2003). Enterprise
Integration Patterns: Designing, Building, and De-
ploying Messaging Solutions. Addison-Wesley.
ISBN 0-321-20068-3.
• Holub, Allen (2004). Holub on Patterns. Apress.
ISBN 1-59059-388-X.
• Kircher, Michael; Völter, Markus; Zdun, Uwe
(2005). Remoting Patterns: Foundations of Enter-
prise, Internet and Realtime Distributed Object Mid-
dleware. John Wiley & Sons. ISBN 0-470-85662-
9.
Chapter 2
Creational Patterns
2.1 Creational pattern
In software engineering, creational design patterns are
design patterns that deal with object creation mecha-
nisms, trying to create objects in a manner suitable to the
situation. The basic form of object creation could result
in design problems or in added complexity to the design.
Creational design patterns solve this problem by somehow
controlling this object creation.
Creational design patterns are composed of two domi-
nant ideas. One is encapsulating knowledge about which
concrete classes the system uses. Another is hiding
how instances of these concrete classes are created and
combined.[1]
Creational design patterns are further categorized into
Object-creational patterns and Class-creational patterns,
where Object-creational patterns deal with Object cre-
ation and Class-creational patterns deal with Class-
instantiation. In greater details, Object-creational pat-
terns defer part of its object creation to another object,
while Class-creational patterns defer its object creation to
subclasses.[2]
Five well-known design patterns that are parts of cre-
ational patterns are the
• Abstract factory pattern, which provides an inter-
face for creating related or dependent objects with-
out specifying the objects’ concrete classes.[3]
• Builder pattern, which separates the construction of
a complex object from its representation so that the
same construction process can create different rep-
resentations.
• Factory method pattern, which allows a class to de-
fer instantiation to subclasses.[4]
• Prototype pattern, which specifies the kind of object
to create using a prototypical instance, and creates
new objects by cloning this prototype.
• Singleton pattern, which ensures that a class only has
one instance, and provides a global point of access
to it.[5]
6
2.1.1 Definition
The creational patterns aim to separate a system from how
its objects are created, composed, and represented. They
increase the system’s flexibility in terms of the what, who,
how, and when of object creation..[6]
2.1.2 Usage
As modern software engineering depends more on object
composition than class inheritance, emphasis shifts away
from hard-coding behaviors toward defining a smaller
set of basic behaviors that can be composed into more
complex ones.[7] Hard-coding behaviors are inflexible
because they require overriding or re-implementing the
whole thing in order to change parts of the design. Addi-
tionally, hard-coding does not promote reuse and is hard
to keep track of errors. For these reasons, creational pat-
terns are more useful than hard-coding behaviors. Cre-
ational patterns make design become more flexible. They
provide different ways to remove explicit references in
the concrete classes from the code that needs to instanti-
ate them.[8] In other words, they create independency for
objects and classes.
Consider applying creational patterns when:
• A system should be independent of how its objects
and products are created.
• A set of related objects is designed to be used to-
gether.
• Hiding the implementations of a class library or
product, revealing only their interfaces.
• Constructing different representation of indepen-
dent complex objects.
• A class wants its subclass to implement the object it
creates.
• The class instantiations are specified at run-time.
• There must be a single instance and client can access
this instance at all times.
• Instance should be extensible without being modi-
fied.
2.1. CREATIONAL PATTERN
2.1.3 Structure
Creational Pattern class diagram.
Below is a simple class diagram that most creational pat-
terns have in common. Note that different creational pat-
terns require additional and different participated classes.
Participants:
• Creator: Declares object interface. Returns object.
• ConcreteCreator: Implements object’s interface.
2.1.4 Examples
Some examples of creational design patterns include:
• Abstract factory pattern: centralize decision of what
factory to instantiate
• Factory method pattern: centralize creation of an
object of a specific type choosing one of several im-
plementations
• Builder pattern: separate the construction of a com-
plex object from its representation so that the same
construction process can create different represen-
tations
• Dependency Injection pattern: separate object cre-
ation from an application
• Lazy initialization pattern: tactic of delaying the
creation of an object, the calculation of a value, or
some other expensive process until the first time it is
needed
7
• Object pool pattern: avoid expensive acquisition and
release of resources by recycling objects that are no
longer in use
• Prototype pattern: used when the type of objects
to create is determined by a prototypical instance,
which is cloned to produce new objects
• Singleton pattern: restrict instantiation of a class to
one object
2.1.5 See also
• Constructor
• Behavioral pattern
• Concurrency pattern
• Structural pattern
2.1.6 References
[1] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlis-
sides, John (1995). Design Patterns. Massachusetts:
Addison-Wesley. p. 81. ISBN 978-0-201-63361-0. Re-
trieved 2015-05-22.
[2] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlis-
sides, John (1995). Design Patterns. Massachusetts:
Addison-Wesley. ISBN 978-0-201-63361-0. Retrieved
2015-05-22.
[3] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
Head First Design Patterns. California: O'Reilly Media.
p. 156. ISBN 978-0-596-00712-6. Retrieved 2015-05-
22.
[4] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
Head First Design Patterns. California: O'Reilly Media.
p. 134. ISBN 978-0-596-00712-6. Retrieved 2015-05-
22.
[5] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
Head First Design Patterns. California: O'Reilly Media.
p. 177. ISBN 978-0-596-00712-6. Retrieved 2015-05-
22.
[6] Judith, Bishop (2007). C# 3.0 Design Patterns. Califor-
nia: O'Reilly Media. p. 336. ISBN 978-0-596-52773-0.
Retrieved 2015-05-22.
[7] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlis-
sides, John (1995). Design Patterns. Massachusetts:
Addison-Wesley. p. 84. ISBN 978-0-201-63361-0. Re-
trieved 2015-05-22.
[8] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlis-
sides, John (1995). Design Patterns. Massachusetts:
Addison-Wesley. p. 85. ISBN 978-0-201-63361-0. Re-
trieved 2015-05-22.
8 CHAPTER 2. CREATIONAL PATTERNS
2.2 Abstract factory pattern
The abstract factory pattern provides a way to encap-
sulate a group of individual factories that have a common
theme without specifying their concrete classes.[1] In nor-
mal usage, the client software creates a concrete imple-
mentation of the abstract factory and then uses the generic
interface of the factory to create the concrete objects that
are part of the theme. The client doesn't know (or care)
which concrete objects it gets from each of these inter-
nal factories, since it uses only the generic interfaces of
their products.[1] This pattern separates the details of im-
plementation of a set of objects from their general usage
and relies on object composition, as object creation is im-
plemented in methods exposed in the factory interface.[2]
An example of this would be an abstract factory class
DocumentCreator that provides interfaces to create a
number of products (e.g. createLetter() and createRe-
sume()). The system would have any number of derived
concrete versions of the DocumentCreator class like Fan-
cyDocumentCreator or ModernDocumentCreator, each
with a different implementation of createLetter() and cre-
ateResume() that would create a corresponding object
like FancyLetter or ModernResume. Each of these prod-
ucts is derived from a simple abstract class like Letter
or Resume of which the client is aware. The client code
would get an appropriate instance of the DocumentCre-
ator and call its factory methods. Each of the resulting
objects would be created from the same DocumentCre-
ator implementation and would share a common theme
(they would all be fancy or modern objects). The client
would only need to know how to handle the abstract Let-
ter or Resume class, not the specific version that it got
from the concrete factory.
A factory is the location of a concrete class in the code
at which objects are constructed. The intent in employing
the pattern is to insulate the creation of objects from their
usage and to create families of related objects without
having to depend on their concrete classes.[2] This allows
for new derived types to be introduced with no change to
the code that uses the base class.
Use of this pattern makes it possible to interchange con-
crete implementations without changing the code that
uses them, even at runtime. However, employment of
this pattern, as with similar design patterns, may result in
unnecessary complexity and extra work in the initial writ-
ing of code. Additionally, higher levels of separation and
abstraction can result in systems that are more difficult to
debug and maintain.
2.2.1 Definition
The method createButton on the GUIFactory interface
The essence of the Abstract Factory Pattern is to “Provide returns objects of type Button. What implementation of
an interface for creating families of related or dependent Button is returned depends on which implementation of
objects without specifying their concrete classes.”.[3] GUIFactory is handling the method call.
2.2.2 Usage
The factory determines the actual concrete type of object
to be created, and it is here that the object is actually cre-
ated (in C++, for instance, by the new operator). How-
ever, the factory only returns an abstract pointer to the
created concrete object.
This insulates client code from object creation by having
clients ask a factory object to create an object of the de-
sired abstract type and to return an abstract pointer to the
object.[4]
As the factory only returns an abstract pointer, the client
code (that requested the object from the factory) does not
know — and is not burdened by — the actual concrete
type of the object that was just created. However, the
type of a concrete object (and hence a concrete factory)
is known by the abstract factory; for instance, the factory
may read it from a configuration file. The client has no
need to specify the type, since it has already been speci-
fied in the configuration file. In particular, this means:
• The client code has no knowledge whatsoever of the
concrete type, not needing to include any header
files or class declarations related to it. The client
code deals only with the abstract type. Objects of a
concrete type are indeed created by the factory, but
the client code accesses such objects only through
their abstract interface.[5]
• Adding new concrete types is done by modifying the
client code to use a different factory, a modification
that is typically one line in one file. The different
factory then creates objects of a different concrete
type, but still returns a pointer of the same abstract
type as before — thus insulating the client code from
change. This is significantly easier than modify-
ing the client code to instantiate a new type, which
would require changing every location in the code
where a new object is created (as well as making sure
that all such code locations also have knowledge of
the new concrete type, by including for instance a
concrete class header file). If all factory objects are
stored globally in a singleton object, and all client
code goes through the singleton to access the proper
factory for object creation, then changing factories
is as easy as changing the singleton object.[5]
2.2.3 Structure
Class diagram
2.2. ABSTRACT FACTORY PATTERN 9

button Return a new OSXButton class WinButton im-

plementing Button is method paint() is Render a but-
ton in a Windows style class OSXButton implementing
Button is method paint() is Render a button in a Mac
OS X style class Application is constructor Applica-
tion(factory) is input: the GUIFactory factory used
to create buttons Button button := factory.createButton()
button.paint() Read the configuration file If the OS speci-
fied in the configuration file is Windows, then Construct
a WinFactory Construct an Application with WinFac-
tory else Construct an OSXFactory Construct an Ap-
plication with OSXFactory

UML class diagram 2.2.5 C# example

«interface» «import» Client

interface IButton { void Paint(); } interface IGUIFactory
AbstractFactory

CreateProductA()
{ IButton CreateButton(); } class WinFactory : IGU-
CreateProductB()
IFactory { public IButton CreateButton() { return new
«interface»
WinButton(); } } class OSXFactory : IGUIFactory {
«import»

ConcreteFactory2 ConcreteFactory1
AbstractProductA

«import»
public IButton CreateButton() { return new OSXBut-
CreateProductA()

CreateProductB()
CreateProductA()

CreateProductB()
ton(); } } class WinButton : IButton { public void
«instantiate»
ProductA1 ProductA2
Paint() { //Render a button in a Windows style } } class
«instantiate» OSXButton : IButton { public void Paint() { //Render
«instantiate»
«interface»
AbstractProductB a button in a Mac OS X style } } class Program { static
void Main() { var appearance = Settings.Appearance;
ProductB1 ProductB2
IGUIFactory factory; switch (appearance) { case Ap-
«instantiate»
pearance.Win: factory = new WinFactory(); break; case
Appearance.OSX: factory = new OSXFactory(); break;
default: throw new System.NotImplementedException();
} var button = factory.CreateButton(); button.Paint(); }
}
Lepus3 chart (legend)

2.2.6 Java example

public interface IButton { void paint(); } public inter-
face IGUIFactory { public IButton createButton(); }
public class WinFactory implements IGUIFactory {
@Override public IButton createButton() { return new
WinButton(); } } public class OSXFactory implements
IGUIFactory { @Override public IButton createButton()
{ return new OSXButton(); } } public class WinButton
implements IButton { @Override public void paint()
{ System.out.println(“WinButton”); } } public class
2.2.4 Pseudocode OSXButton implements IButton { @Override public
void paint() { System.out.println(“OSX button”); } }
It should render a button in either a Windows style or public class Main { public static void main(String[] args)
Mac OS X style depending on which kind of factory was throws Exception { IGUIFactory factory = null; String
used. Note that the Application has no idea what kind of appearance = randomAppearance();//current operating
GUIFactory it is given or even what kind of Button that system if (appearance.equals(“osx”)) { factory = new
factory creates. OSXFactory(); } else if(appearance.equals(“windows”))
interface Button is method paint() interface GUIFac- { factory = new WinFactory(); } else { throw new
tory is method createButton() output: a button class Exception(“No such operating system”); } IButton
WinFactory implementing GUIFactory is method cre- button = factory.createButton(); button.paint(); } /**
ateButton() is output: a Windows button Return a new * This is just for the sake of testing this program, and
WinButton class OSXFactory implementing GUIFac- doesn't have to do * with Abstract Factory pattern. *
tory is method createButton() is output: an OS X @return */ public static String randomAppearance()
10
{ String[] appearanceArr = new String[3]; appear- 2.2.10 References
anceArr[0] = “osx"; appearanceArr[1] = “windows";
appearanceArr[2] = “error"; java.util.Random rand = [1] Freeman, Eric; Robson, Elisabeth; Sierra, Kathy; Bates,
new java.util.Random(); int randNum = rand.nextInt(3); Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
return appearanceArr[randNum]; } }
2.2.7 PHP example
interface Button { public function paint(); } interface
GUIFactory { public function createButton(): Button;
} class WinFactory implements GUIFactory { public
function createButton(): Button { return new WinBut-
ton(); } } class OSXFactory implements GUIFactory
{ public function createButton(): Button { return new
OSXButton(); } } class WinButton implements Button
{ public function paint() { echo “Windows Button";
} } class OSXButton implements Button { public
function paint() { echo “OSX Button"; } } $appearance
= “osx"; $factory = NULL; switch ($appearance) { case
“win": $factory = new WinFactory(); break; case “osx":
$factory = new OSXFactory(); break; default: break; }
$button = $factory->createButton(); $button->paint();
2.2.8 Crystal example
abstract class Button abstract def paint end class Lin-
uxButton < Button def paint “Render a button in a
Linux style” end end class WindowsButton < Button
def paint “Render a button in a Windows style” end
end class MacOSButton < Button def paint “Render
a button in a MacOS style” end end abstract class
GUIFactory abstract def create_button : Button end
class LinuxFactory < GUIFactory def create_button
return LinuxButton.new end end class WindowsFactory
< GUIFactory def create_button return WindowsBut-
ton.new end end class MacOSFactory < GUIFactory
def create_button return MacOSButton.new end end
# Run program appearance = “linux” case appear-
ance when “linux” factory = LinuxFactory.new when
“osx” factory = MacOSFactory.new when “win” fac- The builder pattern is an object creation software design
tory = WindowsFactory.new end if factory button = pattern. Unlike the abstract factory pattern and the
factory.create_button result = button.paint puts result end factory method pattern whose intention is to enable
2.2.9 See also
• Concrete class
• Factory method pattern
• Object creation
• Software design pattern
CHAPTER 2. CREATIONAL PATTERNS
“Head First Design Patterns” (paperback). 1. O'REILLY:
156. ISBN 978-0-596-00712-6. Retrieved 2012-09-12.
[2] Freeman, Eric; Robson, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
“Head First Design Patterns” (paperback). 1. O'REILLY:
162. ISBN 978-0-596-00712-6. Retrieved 2012-09-12.
[3] Gamma, Erich; Richard Helm; Ralph Johnson; John M.
Vlissides (2009-10-23). “Design Patterns: Abstract Fac-
tory”. informIT. Archived from the original on 2009-10-
23. Retrieved 2012-05-16. Object Creational: Abstract
Factory: Intent: Provide an interface for creating families
of related or dependent objects without specifying their
concrete classes.
[4] Veeneman, David (2009-10-23). “Object Design for the
Perplexed”. The Code Project. Archived from the orig-
inal on 2011-09-18. Retrieved 2012-05-16. The factory
insulates the client from changes to the product or how it
is created, and it can provide this insulation across objects
derived from very different abstract interfaces.
[5] “Abstract Factory: Implementation”. OODesign.com.
Retrieved 2012-05-16.
2.2.11 External links
• Media related to Abstract factory at Wikimedia
Commons
• Abstract Factory UML diagram + formal specifica-
tion in LePUS3 and Class-Z (a Design Description
Language)
• Abstract Factory Abstract Factory implementation
example
2.3 Builder pattern
polymorphism, the intention of the builder pattern is to
find a solution to the telescoping constructor anti-pattern.
The telescoping constructor anti-pattern occurs when the
increase of object constructor parameter combination
leads to an exponential list of constructors. Instead of
using numerous constructors, the builder pattern uses an-
other object, a builder, that receives each initialization
parameter step by step and then returns the resulting con-
structed object at once.
The builder pattern has another benefit. It can be used
for objects that contain flat data (html code, SQL query,
X.509 certificate...), that is to say, data that can't be easily
2.3. BUILDER PATTERN 11

edited. This type of data can't be edited step by step and 2.3.5 Pseudocode
must be edited at once.
We have a Car class. The problem is that a car has many
Builder often builds a Composite. Often, designs start out
options. The combination of each option would lead to a
using Factory Method (less complicated, more customiz-
huge list of constructors for this class. So we will create a
able, subclasses proliferate) and evolve toward Abstract
builder class, CarBuilder. We will send to the CarBuilder
Factory, Prototype, or Builder (more flexible, more com-
each car option step by step and then construct the final
plex) as the designer discovers where more flexibility is
car with the right options:
needed. Sometimes creational patterns are complemen-
tary: Builder can use one of the other patterns to imple- class Car is Can have GPS, trip computer and various
ment which components are built. Builders are good can- numbers of seats. Can be a city car, a sports car, or a
didates for a fluent interface.[1] cabriolet. class CarBuilder is method getResult() is out-
put: a Car with the right options Construct and return
the car. method setSeats(number) is input: the number
2.3.1 Definition of seats the car may have. Tell the builder the number
of seats. method setCityCar() is Make the builder re-
The intent of the Builder design pattern is to separate the member that the car is a city car. method setCabriolet()
construction of a complex object from its representation. is Make the builder remember that the car is a cabrio-
By doing so the same construction process can create dif- let. method setSportsCar() is Make the builder remem-
ferent representations. [2] ber that the car is a sports car. method setTripCom-
puter() is Make the builder remember that the car has
a trip computer. method unsetTripComputer() is Make
2.3.2 Advantages [3] the builder remember that the car does not have a trip
computer. method setGPS() is Make the builder remem-
ber that the car has a global positioning system. method
• Allows you to vary a product’s internal representa-
unsetGPS() is Make the builder remember that the car
tion.
does not have a global positioning system. Construct
a CarBuilder called carBuilder carBuilder.setSeats(2)
• Encapsulates code for construction and representa-
carBuilder.setSportsCar() carBuilder.setTripComputer()
tion.
carBuilder.unsetGPS() car := carBuilder.getResult()
• Provides control over steps of construction process. Of course one could dispense with Builder and just do
this:
car = new Car(); car.seats = 2; car.type =
2.3.3 Disadvantages[3] CarType.SportsCar; car.setTripComputer();
car.unsetGPS(); car.isValid();
• Requires creating a separate ConcreteBuilder for
So this indicates that the Builder pattern is more than
each different type of Product.
just a means to limit constructor proliferation. It removes
what could be a complex building process from being the
responsibility of the user of the object that is built. It
2.3.4 Structure also allows for inserting new implementations of how an
object is built without disturbing the client code.
Director Builder ConcreteBuilder

builder : Builder
buildPart() buildPart()
construct() getResult() : Product 2.3.6 Examples
<< create >>
this.builder.buildPart();

Product
C#

/// <summary> /// Represents a product created by

Builder Structure the builder /// </summary> public class Car { pub-
lic Car() { } public int Wheels { get; set; } public
string Colour { get; set; } } /// <summary> /// The
builder abstraction /// </summary> public interface
Builder Abstract interface for creating objects (prod-
ICarBuilder { // Adding NotNull attribute to prevent
uct).
null input argument void SetColour([NotNull]string
colour); // Adding NotNull attribute to prevent null
ConcreteBuilder Provides implementation for Builder. input argument void SetWheels([NotNull]int count);
It is an object able to construct other objects. Con- Car GetResult(); } /// <summary> /// Concrete builder
structs and assembles parts to build the objects. implementation /// </summary> public class CarBuilder
12
: ICarBuilder { private Car _car; public CarBuilder()
{ this._car = new Car(); } public void SetColour(string
colour) { this._car.Colour = colour; } public void
SetWheels(int count) { this._car.Wheels = count; }
public Car GetResult() { return this._car; } } /// <sum-
mary> /// The director /// </summary> public class
CarBuildDirector { public Car Construct() { CarBuilder
builder = new CarBuilder(); builder.SetColour(“Red”);
builder.SetWheels(4); return builder.GetResult(); } }
The Director assembles a car instance in the example
above, delegating the construction to a separate builder
object.
C++
////// Product declarations and inline impl. (possibly
Product.h) ////// class Product{ public: // use this class
to construct Product class Builder; private: // variables
in need of initialization to make valid object const int i;
const float f; const char c; // Only one simple constructor
- rest is handled by Builder Product( const int i, const
float f, const char c ) : i(i), f(f), c(c){} public: // Product
specific functionality void print(); void doSomething();
void doSomethingElse(); }; class Product::Builder{
private: // variables needed for construction of object
of Product class int i; float f; char c; public: // default
values for variables static const constexpr int defaultI =
1; static const constexpr float defaultF = 3.1415f; static
const constexpr char defaultC = 'a'; // create Builder
with default values assigned // (in C++11 they can be
simply assigned above on declaration instead) Builder()
: i( defaultI ), f( defaultF ), c( defaultC ){ } // sets
custom values for Product creation // returns Builder for
shorthand inline usage (same way as cout <<) Builder&
setI( const int i ){ this->i = i; return *this; } Builder&
setF( const float f ){ this->f = f; return *this; } Builder&
setC( const char c ){ this->c = c; return *this; } //
prepare specific frequently desired Product // returns
Builder for shorthand inline usage (same way as cout
<<) Builder& setProductP(){ this->i = 42; this->f =
−1.0f/12.0f; this->c = '@'; return *this; } // produce
desired Product Product build(){ // here optionaly check
variable consistency // and also if Product is buildable
from given information return Product( this->i, this->f,
this->c ); } };
///// Product implementation (possibly Product.cpp)
///// #include <iostream> void Product::print(){ using
namespace std; cout << “Product internals dump:"
<< endl; cout << “i: " << this->i << endl; cout <<
“f: " << this->f << endl; cout << “c: " << this->c
<< endl; } void Product::doSomething(){} void Prod-
uct::doSomethingElse(){}
//////////////////// Usage of Builder (replaces Director
from diagram) int main(){ // simple usage Product p1
= Product::Builder().setI(2).setF(0.5f).setC('x').build();
p1.print(); // test p1 // advanced usage Product::Builder
CHAPTER 2. CREATIONAL PATTERNS
b; b.setProductP(); Product p2 = b.build(); // get Product
P object b.setC('!'); // customize Product P Product p3
= b.build(); p2.print(); // test p2 p3.print(); // test p3 }
Java
/** * Represents the product created by the builder.
*/ class Car { private int wheels; private String color;
public Car() { } @Override public String toString()
{ return “Car [wheels = " + wheels + ", color = " +
color + "]"; } public int getWheels() { return wheels;
} public void setWheels(final int wheels) { this.wheels
= wheels; } public String getColor() { return color; }
public void setColor(final String color) { this.color =
color; } } /** * The builder abstraction. */ interface
CarBuilder { CarBuilder setWheels(final int wheels);
CarBuilder setColor(final String color); Car build();
} class CarBuilderImpl implements CarBuilder { pri-
vate Car car; public CarBuilderImpl() { car = new
Car(); } @Override public CarBuilder setWheels(final
int wheels) { car.setWheels(wheels); return this; }
@Override public CarBuilder setColor(final String
color) { car.setColor(color); return this; } @Over-
ride public Car build() { return car; } } public
class CarBuildDirector { private CarBuilder builder;
public CarBuildDirector(final CarBuilder builder) {
this.builder = builder; } public Car construct() { return
builder.setWheels(4).setColor(“Red”).build(); } public
static void main(final String[] arguments) { CarBuilder
builder = new CarBuilderImpl(); CarBuildDirector
carBuildDirector = new CarBuildDirector(builder);
System.out.println(carBuildDirector.construct()); } }
PHP
abstract class GetterSetter { public function
__get($name) { $method = sprintf('get%s’, uc-
first($name)); if (!method_exists($this, $method))
{ throw new Exception(); } return $this-
>$method(); } public function __set($name, $v)
{ $method = sprintf('set%s’, ucfirst($name)); if
(!method_exists($this, $method)) { throw new Excep-
tion(); } $this->$method($v); } } //Represents a product
created by the builder class Car extends GetterSetter {
private $wheels; private $colour; function __construct()
{ } public function setWheels($wheels) { $this->wheels
= $wheels; } public function getWheels() { return
$this->wheels; } public function setColour($colour)
{ $this->colour = $colour; } public function get-
Colour() { return $this->colour; } } //The builder
abstraction interface ICarBuilder { public function
SetColour($colour); public function SetWheels($count);
public function GetResult(); } //Concrete builder im-
plementation class CarBuilder implements ICarBuilder
{ private $_car; function __construct() { $this->_car
2.4. FACTORY METHOD PATTERN 13

= new Car(); } public function SetColour($colour) { 2.4 Factory method pattern

$this->_car->setColour($colour); } public function
SetWheels($count) { $this->_car->setWheels($count);
} public function GetResult() { return $this->_car;
} } //The director class CarBuildDirector { public
$builder; function __construct($color = “White”,
$wheels = 4) { $this->builder = new CarBuilder();
$this->builder->SetColour($color); $this->builder-
>SetWheels($wheels); } public function GetResult() {
return $this->builder->GetResult(); } }
In class-based programming, the factory method pattern
is a creational pattern that uses factory methods to deal
with the problem of creating objects without having to
specify the exact class of the object that will be cre-
ated. This is done by creating objects by calling a fac-
tory method—either specified in an interface and imple-
mented by child classes, or implemented in a base class
and optionally overridden by derived classes—rather than
by calling a constructor.

Crystal 2.4.1 Definition

class Car property wheels : Int32 property seats : Int32
property color : String def initialize(@wheels = 4, @seats
= 4, @color = “Black”) end end abstract class Builder
abstract def set_wheels(number : Int32) abstract def
set_seats(number : Int32) abstract def set_color(color
: String) abstract def get_result end class CarBuilder <
Builder private getter car : Car def initialize @car =
Car.new end def set_wheels(value : Int32) @car.wheels
= value end def set_seats(value : Int32) @car.seats =
value end def set_color(value : String) @car.color =
value end def get_result return @car end end class Car-
BuilderDirector def self.construct : Car builder = Car-
Builder.new builder.set_wheels(8) builder.set_seats(4)
builder.set_color(“Red”) builder.get_result end end car
= CarBuilderDirector.construct p car
2.3.7 See also
• Currying
“Define an interface for creating an object, but let sub-
classes decide which class to instantiate. The Factory
method lets a class defer instantiation it uses to sub-
classes.” (Gang Of Four)
Creating an object often requires complex processes not
appropriate to include within a composing object. The
object’s creation may lead to a significant duplication of
code, may require information not accessible to the com-
posing object, may not provide a sufficient level of ab-
straction, or may otherwise not be part of the compos-
ing object’s concerns. The factory method design pattern
handles these problems by defining a separate method for
creating the objects, which subclasses can then override
to specify the derived type of product that will be created.
The factory method pattern relies on inheritance, as ob-
ject creation is delegated to subclasses that implement the
factory method to create objects.[1]
2.4.2 Example
Structure

2.3.8 References

[1] Nahavandipoor, Vandad. “Swift Weekly - Issue 05 - The

Builder Pattern and Fluent Interface”. Github.com.

[2] Gang Of Four

[3] “Index of /archive/2010/winter/51023-1/presentations”

(PDF). www.classes.cs.uchicago.edu. Retrieved 2016-03-
03.

Room is the base class for a final product (Magic-

2.3.9 External links Room or OrdinaryRoom). MazeGame declares the ab-
stract factory method to produce such a base product.
• The JavaWorld article Build user interfaces without MagicRoom or OrdinaryRoom are subclasses of the
getters and setters (Allen Holub) shows the complete base product implementing the final product. Magic-
Java source code for a Builder. MazeGame and OrdinaryMazeGame are subclasses of
MazeGame implementing the factory method producing
• Item 2: Consider a builder by Joshua Bloch the final products. Thus factory methods decouple callers
14 CHAPTER 2. CREATIONAL PATTERNS

(MazeGame) from the implementation of the concrete C# Factory pattern deals with the instantiation of ob-
classes. This makes the “new” Operator redundant, al- jects without exposing the instantiation logic. In other
lows adherence to the Open/closed principle and makes words, a Factory is actually a creator of objects which
the final product more flexible in the event of change. have a common interface.
//Empty vocabulary of actual object public interface
IPerson { string GetName(); } public class Villager :
Example implementations IPerson { public string GetName() { return “Village
Person"; } } public class CityPerson : IPerson { public
Java A maze game may be played in two modes, one string GetName() { return “City Person"; } } public
with regular rooms that are only connected with adjacent enum PersonType { Rural, Urban } /// <summary>
rooms, and one with magic rooms that allow players to /// Implementation of Factory - Used to create objects
be transported at random (this Java example is similar to /// </summary> public class Factory { public IPerson
one in the book Design Patterns). The MazeGame uses GetPerson(PersonType type) { switch (type) { case
Rooms but it puts the responsibility of creating Rooms PersonType.Rural: return new Villager(); case Person-
to its subclasses which create the concrete classes. The Type.Urban: return new CityPerson(); default: throw
regular game mode could use this template method: new NotSupportedException(); } } }
public abstract class MazeGame { private final
List<Room> rooms = new ArrayList<>(); public In the above code you can see the creation of one interface
MazeGame() { Room room1 = makeRoom(); Room called IPerson and two implementations called Villager
room2 = makeRoom(); room1.connect(room2); and CityPerson. Based on the type passed into the Fac-
rooms.add(room1); rooms.add(room2); } abstract pro- tory object, we are returning the original concrete object
tected Room makeRoom(); } as the interface IPerson.
A factory method is just an addition to Factory class. It
In the above snippet, the MazeGame constructor is a creates the object of the class through interfaces but on
template method that makes some common logic. It the other hand, it also lets the subclass decide which class
refers to the makeRoom factory method that encapsulates is instantiated.
the creation of rooms such that other rooms can be used public interface IProduct { string GetName(); string
in a subclass. To implement the other game mode that SetPrice(double price); } public class Phone : IProduct {
has magic rooms, it suffices to override the makeRoom private double _price; public string GetName() { return
method: “Apple TouchPad"; } public string SetPrice(double
public class MagicMazeGame extends MazeGame { price) { this._price = price; return “success"; } } /*
@Override protected Room makeRoom() { return new Almost same as Factory, just an additional exposure
MagicRoom(); } } public class OrdinaryMazeGame to do something with the created method */ public
extends MazeGame { @Override protected Room make- abstract class ProductAbstractFactory { protected
Room() { return new OrdinaryRoom(); } } MazeGame abstract IProduct DoSomething(); public IProduct
ordinaryGame = new OrdinaryMazeGame(); MazeGame GetObject() // Implementation of Factory Method. {
magicGame = new MagicMazeGame(); return this.DoSomething(); } } public class PhoneCon-
creteFactory : ProductAbstractFactory { protected
override IProduct DoSomething() { IProduct product =
new Phone(); //Do something with the object after you
get the object. product.SetPrice(20.30); return product;
PHP Another example in PHP follows, this time us-
}}
ing interface implementations as opposed to subclassing
(however the same can be achieved through subclassing).
It is important to note that the factory method can also be You can see we have used GetObject in concreteFactory.
defined as public and called directly by the client code (in As a result, you can easily call DoSomething() from it to
contrast with the Java example above). get the IProduct. You might also write your custom logic
after getting the object in the concrete Factory Method.
/* Factory and car interfaces */ interface CarFactory
The GetObject is made abstract in the Factory interface.
{ public function makeCar(); } interface Car { public
function getType(); } /* Concrete implementations of
the factory and car */ class SedanFactory implements 2.4.3 Uses
CarFactory { public function makeCar() { return new
Sedan(); } } class Sedan implements Car { public func- • In ADO.NET, IDbCommand.CreateParameter is
tion getType() { return 'Sedan'; } } /* Client */ $factory an example of the use of factory method to connect
= new SedanFactory(); $car = $factory->makeCar(); parallel class hierarchies.
print $car->getType();
• In Qt, QMainWindow::createPopupMenu is a fac-
2.5. LAZY INITIALIZATION 15

tory method declared in a framework that can be 2.5 Lazy initialization

overridden in application code.
In computer programming, lazy initialization is the tac-
• In Java, several factories are used in
tic of delaying the creation of an object, the calculation
the javax.xml.parsers package. e.g.
of a value, or some other expensive process until the first
javax.xml.parsers.DocumentBuilderFactory or
time it is needed. It is a kind of lazy evaluation that
javax.xml.parsers.SAXParserFactory.
refers specifically to the instantiation of objects or other
resources.
2.4.4 See also This is typically accomplished by augmenting an accessor
method (or property getter) to check whether a private
• Design Patterns, the highly influential book member, acting as a cache, has already been initialized.
If it has, it is returned straight away. If not, a new instance
• Design pattern, overview of design patterns in gen- is created, placed into the member variable, and returned
eral to the caller just-in-time for its first use.
If objects have properties that are rarely used, this can
• Abstract factory pattern, a pattern often imple-
improve startup speed. Mean average program perfor-
mented using factory methods
mance may be slightly worse in terms of memory (for the
• Builder pattern, another creational pattern condition variables) and and execution cycles (to check
them), but the impact of object instantiation is spread in
• Template method pattern, which may call factory time (“amortized”) rather than concentrated in the startup
methods phase of a system, and thus median response times can be
greatly improved.
• Joshua Bloch's idea of a static factory method, which
In multithreaded code, access to lazy-initialized ob-
he says has no direct equivalent in Design Patterns.
jects/state must be synchronized to guard against race
conditions.
2.4.5 References
2.5.1 The “lazy factory”
[1] Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bert,
Bates (2004). Hendrickson, Mike; Loukides, Mike, eds.
“Head First Design Patterns” (paperback). 1. O'REILLY:
In a software design pattern view, lazy initialization is of-
162. ISBN 978-0-596-00712-6. Retrieved 2012-09-12. ten used together with a factory method pattern. This
combines three ideas:

• Martin Fowler; Kent Beck; John Brant; William

Opdyke; Don Roberts (June 1999). Refactoring: • Using a factory method to create instances of a class
Improving the Design of Existing Code. Addison- (factory method pattern)
Wesley. ISBN 0-201-48567-2. • Storing the instances in a map, and returning the
same instance to each request for an instance with
• Gamma, Erich; Helm, Richard; Johnson, Ralph;
same parameters (multiton pattern)
Vlissides, John (1994). Design Patterns: Elements
of Reusable Object-Oriented Software. Addison- • Using lazy initialization to instantiate the object the
Wesley. ISBN 0-201-63361-2. first time it is requested (lazy initialization pattern)
• Cox, Brad J.; (1986). Object-oriented programming:
an evolutionary approach. Addison-Wesley. ISBN 2.5.2 Examples
978-0-201-10393-9.
Actionscript 3
• Cohen, Tal; Gil, Joseph (2007). “Better Construc-
tion with Factories” (PDF). Journal of Object Tech-
The following is an example of a class with Lazy initial-
nology. Bertrand Meyer. Retrieved 2007-03-12.
ization implemented in Actionscript:
package examples.lazyinstantiation { public class
2.4.6 External links Fruit { private var _typeName:String; private static
var instancesByTypeName:Dictionary = new Dictio-
• Factory method in UML and in LePUS3 (a Design nary(); public function Fruit(typeName:String):void
Description Language) { this._typeName = typeName; } public function get
typeName():String { return _typeName; } public static
• Consider static factory methods by Joshua Bloch function getFruitByTypeName(typeName:String):Fruit
16 CHAPTER 2. CREATIONAL PATTERNS

{ return instancesByTypeName[typeName] ||= new if (0 == strcmp(name, f->name)) return f; if (!(f = mal-

Fruit(typeName); } public static function print-
CurrentTypes():void { for each (var fruit:Fruit in
instancesByTypeName) { // iterates through each value
trace(fruit.typeName); } } } }
Basic Usage:
loc(sizeof(struct fruit)))) return NULL; if (!(f->name
= strdup(name))) { free(f); return NULL; } f->number
= ++seq; f->next = fruit_list; fruit_list = f; return f; }
void print_fruit_list(FILE *file) { struct fruit *f; for (f
= fruit_list; f; f = f->next) fprintf(file, "%4d %s\n”,
f->number, f->name); }

package { import examples.lazyinstantiation; pub-

lic class Main { public function Main():void
{ Fruit.getFruitByTypeName(“Banana”);
Fruit.printCurrentTypes();
Fruit.getFruitByTypeName(“Apple”);
Fruit.printCurrentTypes();
Fruit.getFruitByTypeName(“Banana”);
Fruit.printCurrentTypes(); } } }
main.c:
#include <stdlib.h> #include <stdio.h> #include “fruit.h”
int main(int argc, char *argv[]) { int i; struct fruit *f;
if (argc < 2) { fprintf(stderr, “Usage: fruits fruit-name
[...]\n”); exit(1); } for (i = 1; i < argc; i++) { if ((f =
get_fruit(argv[i]))) { printf(“Fruit %s: number %d\n”,
argv[i], f->number); } } printf(“The following fruits
have been generated:\n”); print_fruit_list(stdout); return
0; }

In C, lazy evaluation would normally be implemented in- C#

side a single function, or a single source file, using static
variables. In .NET 4.0 Microsoft has included a Lazy class that can
In a function: be used to do lazy loading. Below is some dummy code
that does lazy loading of Class Fruit
#include <string.h> #include <stdlib.h> #include <std-
def.h> #include <stdio.h> struct fruit { char *name; Lazy<Fruit> lazyFruit = new Lazy<Fruit>(); Fruit fruit
struct fruit *next; int number; /* Other members */ }; = lazyFruit.Value;
struct fruit *get_fruit(char *name) { static struct fruit
*fruit_list; static int seq; struct fruit *f; for (f = fruit_list; Here is a dummy example in C#.
f; f = f->next) if (0 == strcmp(name, f->name)) return
f; if (!(f = malloc(sizeof(struct fruit)))) return NULL; The Fruit class itself doesn't do anything here, The class
if (!(f->name = strdup(name))) { free(f); return NULL; variable _typesDictionary is a Dictionary/Map used to
} f->number = ++seq; f->next = fruit_list; fruit_list store Fruit instances by typeName.
= f; return f; } /* Example code */ int main(int argc, using System; using System.Collections; using
char *argv[]) { int i; struct fruit *f; if (argc < 2) { System.Collections.Generic; public class Fruit {
fprintf(stderr, “Usage: fruits fruit-name [...]\n”); exit(1); private string _typeName; private static Dictio-
} for (i = 1; i < argc; i++) { if ((f = get_fruit(argv[i]))) { nary<string, Fruit> _typesDictionary = new Dictio-
printf(“Fruit %s: number %d\n”, argv[i], f->number); } nary<string, Fruit>(); private Fruit(String typeName)
} return 0; } { this._typeName = typeName; } public static Fruit
GetFruitByTypeName(string type) { Fruit fruit; if
Using a single source file instead allows the state to be (!_typesDictionary.TryGetValue(type, out fruit)) { //
shared between multiple functions, while still hiding it Lazy initialization fruit = new Fruit(type); _types-
from non-related functions. Dictionary.Add(type, fruit); } return fruit; } public
static void ShowAll() { if (_typesDictionary.Count >
fruit.h: 0) { Console.WriteLine(“Number of instances made
#ifndef _FRUIT_INCLUDED_ #define = {0}", _typesDictionary.Count); foreach (KeyVal-
_FRUIT_INCLUDED_ struct fruit { char *name; struct uePair<string, Fruit> kvp in _typesDictionary) {
fruit *next; int number; /* Other members */ }; struct Console.WriteLine(kvp.Key); } Console.WriteLine();
fruit *get_fruit(char *name); void print_fruit_list(FILE } } public Fruit() { // required so the sample com-
*file); #endif /* _FRUIT_INCLUDED_ */ piles } } class Program { static void Main(string[]
args) { Fruit.GetFruitByTypeName(“Banana”);
Fruit.ShowAll(); Fruit.GetFruitByTypeName(“Apple”);
fruit.c: Fruit.ShowAll(); // returns pre-existing instance
#include <string.h> #include <stdlib.h> #include <std- from first // time Fruit with “Banana” was cre-
def.h> #include <stdio.h> #include “fruit.h” static struct ated Fruit.GetFruitByTypeName(“Banana”);
fruit *fruit_list; static int seq; struct fruit *get_fruit(char Fruit.ShowAll(); Console.ReadLine(); } }
*name) { struct fruit *f; for (f = fruit_list; f; f = f->next)
2.5. LAZY INITIALIZATION 17

A fairly straightforward 'fill-in-the-blanks’ example of a type, e.g. “apple” * postcondition: The Fruit instance
Lazy Initialization design pattern, except that this uses an associated with that type. */ Fruit* Fruit::getFruit(const
enumeration for the type string& type) { map<string,Fruit*>::iterator it =
namespace DesignPatterns.LazyInitialization { pub- types.find(type); // try to find an existing instance; if
lic class LazyFactoryObject { //internal collection not found std::map will return types.end() Fruit *f; if
of items //IDictionaery makes sure they are unique (it == types.end()) { // if no instance with the proper
private IDictionary<LazyObjectType, LazyObject> type was found, make one f = new Fruit(type); // lazy
_LazyObjectList = new Dictionary<LazyObjectType, initialization part types[type] = f; // adding the newly
created Fruit to the types map for later lookup } else
LazyObject>(); //enum for passing name of type
required //avoids passing strings and is part of type { //if already had an instance f = it->second; //The
return value will be the found fruit } return f; } /* *
ahead public enum LazyObjectType { None, Small,
Big, Bigger, Huge } //standard type of object that For example purposes to see pattern in action */ void
Fruit::printCurrentTypes() { if (!types.empty()) { cout
will be constructed public struct LazyObject { public
LazyObjectType Name; public IList<int> Result; } << “Number of instances made = " << types.size()
<< endl; for (map<string,Fruit*>::iterator iter =
//takes type and create 'expensive' list private IList<int>
Result(LazyObjectType name) { IList<int> result = null; types.begin(); iter != types.end(); ++iter) { cout <<
switch (name) { case LazyObjectType.Small: result = (*iter).first << endl; } cout << endl; } } int main(void)
CreateSomeExpensiveList(1, 100); break; case Lazy- { Fruit::getFruit(“Banana”); Fruit::printCurrentTypes();
ObjectType.Big: result = CreateSomeExpensiveList(1, Fruit::getFruit(“Apple”); Fruit::printCurrentTypes();
1000); break; case LazyObjectType.Bigger: result // returns pre-existing instance from first // time Fruit
= CreateSomeExpensiveList(1, 10000); break; case with “Banana” was created Fruit::getFruit(“Banana”);
LazyObjectType.Huge: result = CreateSomeExpen- Fruit::printCurrentTypes(); return 0; } /* OUTPUT:
siveList(1, 100000); break; case LazyObjectType.None: Number of instances made = 1 Banana Number of
result = null; break; default: result = null; break; } return instances made = 2 Apple Banana Number of instances
result; } //not an expensive item to create, but you get the made = 2 Apple Banana */
point //delays creation of some expensive object until
needed private IList<int> CreateSomeExpensiveList(int
start, int end) { IList<int> result = new List<int>(); for
(int counter = 0; counter < (end - start); counter++) Java
{ result.Add(start + counter); } return result; } public
LazyFactoryObject() { //empty constructor } public Here is an example in Java.
LazyObject GetLazyFactoryObject(LazyObjectType import java.util.HashMap; import java.util.Map; im-
name) { //yes, i know it is illiterate and inaccurate port java.util.Map.Entry; public class Program { /**
LazyObject noGoodSomeOne; //retrieves LazyOb- * @param args */ public static void main(String[]
jectType from list via out, else creates one and adds args) { Fruit.getFruitByTypeName(FruitType.banana);
it to list if (!_LazyObjectList.TryGetValue(name, Fruit.showAll(); Fruit.getFruitByTypeName(FruitType.apple);
out noGoodSomeOne)) { noGoodSomeOne = new Fruit.showAll(); Fruit.getFruitByTypeName(FruitType.banana);
LazyObject(); noGoodSomeOne.Name = name; Fruit.showAll(); } } enum FruitType { none, apple, ba-
noGoodSomeOne.Result = this.Result(name); _Lazy- nana, } class Fruit { private static Map<FruitType,
ObjectList.Add(name, noGoodSomeOne); } return Fruit> types = new HashMap<>(); /** * Using a private
noGoodSomeOne; } } } constructor to force the use of the factory method. *
@param type */ private Fruit(FruitType type) { } /** *
Lazy Factory method, gets the Fruit instance associated
with a certain * type. Instantiates new ones as needed.
C++ * @param type Any allowed fruit type, e.g. APPLE *
@return The Fruit instance associated with that type.
Here is an example in C++. */ public static Fruit getFruitByTypeName(FruitType
#include <iostream> #include <string> #include <map> type) { Fruit fruit; // This has concurrency issues. Here
using namespace std; class Fruit { public: static Fruit* the read to types is not synchronized, // so types.put
getFruit(const string& type); static void printCurrent- and types.containsKey might be called at the same
Types(); private: static map<string,Fruit*> types; string time. // Don't be surprised if the data is corrupted.
type; // note: constructor private forcing one to use if (!types.containsKey(type)) { // Lazy initialisation
static getFruit() Fruit(const string& t) : type( t ) {} fruit = new Fruit(type); types.put(type, fruit); } else {
}; //definition needed for using any static member // OK, it’s available currently fruit = types.get(type);
variable map<string,Fruit*> Fruit::types; /* * Lazy } return fruit; } /** * Lazy Factory method, gets
Factory method, gets the Fruit instance associated with the Fruit instance associated with a certain * type.
a * certain type. Instantiates new ones as needed. * Instantiates new ones as needed. Uses double-checked
precondition: type. Any string that describes a fruit locking * pattern for using in highly concurrent en-
18 CHAPTER 2. CREATIONAL PATTERNS

vironments. * @param type Any allowed fruit type, = new Fruit($type); } return self::$types[$type]; }
e.g. APPLE * @return The Fruit instance associated public static function printCurrentTypes() { echo
with that type. */ public static Fruit getFruitByType- 'Number of instances made: ' . count(self::$types)
NameHighConcurrentVersion(FruitType type) { if . "\n"; foreach (array_keys(self::$types) as $key) {
(!types.containsKey(type)) { synchronized (types) echo "$key\n"; } echo "\n"; } } Fruit::getFruit('Apple');
{ // Check again, after having acquired the lock to Fruit::printCurrentTypes(); Fruit::getFruit('Banana');
make sure // the instance was not created meanwhile Fruit::printCurrentTypes(); Fruit::getFruit('Apple');
by another thread if (!types.containsKey(type)) { // Fruit::printCurrentTypes(); /* OUTPUT: Number of
Lazy initialisation types.put(type, new Fruit(type)); instances made: 1 Apple Number of instances made:
} } } return types.get(type); } /** * Displays all 2 Apple Banana Number of instances made: 2 Apple
entered fruits. */ public static void showAll() { Banana */ ?>
if (types.size() > 0) { System.out.println(“Number
of instances made = " + types.size()); for (En-
try<FruitType, Fruit> entry : types.entrySet()) {
String fruit = entry.getKey().toString(); fruit = Char- Python
acter.toUpperCase(fruit.charAt(0)) + fruit.substring(1);
System.out.println(fruit); } System.out.println(); } } } Here is an example in Python.
class Fruit: def __init__(self, item): self.item =
Output item class Fruits: def __init__(self): self.items
= {} def get_fruit(self, item): if item not in
self.items: self.items[item] = Fruit(item) return
Number of instances made = 1 Banana Number of in- self.items[item] if __name__ == '__main__':
stances made = 2 Banana Apple Number of instances fruits = Fruits() print(fruits.get_fruit('Apple'))
made = 2 Banana Apple print(fruits.get_fruit('Lime'))

JavaScript
Here is an example in JavaScript.
var Fruit = (function() { var types = {}; function Fruit()
{}; // count own properties in object function count(obj)
{ return Object.keys(obj).length; } var _static = {
getFruit: function(type) { if (typeof types[type] == 'un-
defined') { types[type] = new Fruit; } return types[type];
}, printCurrentTypes: function () { console.log('Number
of instances made: ' + count(types)); for (var type
in types) { console.log(type); } } }; return _static;
})(); Fruit.getFruit('Apple'); Fruit.printCurrentTypes();
Fruit.getFruit('Banana'); Fruit.printCurrentTypes();
Fruit.getFruit('Apple'); Fruit.printCurrentTypes();
Output
Ruby
Here is an example in Ruby, of lazily initializing an au-
thentication token from a remote service like Google.
The way that @auth_token is cached is also an example
of memoization.
require 'net/http' class Blogger def auth_token
@auth_token ||= (res = Net::HTTP.post_form(uri,
params)) && get_token_from_http_response(res)
end # get_token_from_http_response, uri and
params are defined later in the class end b = Blog-
ger.new b.instance_variable_get(:@auth_token)
# returns nil b.auth_token # returns token
b.instance_variable_get(:@auth_token) # returns to-
ken

Number of instances made: 1 Apple Number of instances

made: 2 Apple Banana Number of instances made: 2 Ap- Smalltalk
ple Banana
Here is an example in Smalltalk, of a typical accessor
method to return the value of a variable using lazy initial-
PHP ization.

Here is an example of lazy initialization in PHP 5: height ^height ifNil: [height := 2.0].

<?php header('Content-type:text/plain; charset=utf-

8'); class Fruit { private $type; private static $types
= array(); private function __construct($type) {
$this->type = $type; } public static function get-
Fruit($type) { // Lazy initialization takes place here
if (!isset(self::$types[$type])) { self::$types[$type]
The 'non-lazy' alternative is to use an initialization
method that is run when the object is created and then
use a simpler accessor method to fetch the value.
initialize height := 2.0 height ^height
2.6. MULTITON PATTERN 19

Note that lazy initialization can also be used in non- • Description from the Portland Pattern Repository
object-oriented languages.
• Lazy Initialization of Application Server Services

Scala • Lazy Inheritance in JavaScript

• Lazy Inheritance in C#
Scala has built-in support for lazy variable initiation.[1]
scala> val x = { println(“Hello”); 99 } Hello x: Int = 99
scala> lazy val y = { println(“Hello!!"); 31 } y: Int = 2.6 Multiton pattern
<lazy> scala> y Hello!! res2: Int = 31 scala> y res3: Int
= 31

Multiton
Crystal -instances: Map<Key, Multiton>
class Fruit private getter type : String @@types =
-Multiton()
{} of String => Fruit def initialize(@type) end def
self.get_fruit_by_type(type : String) @@types[type] +getInstance(): Multiton
||= Fruit.new(type) end def self.show_all puts
“Number of instances made: #{@@types.size}"
UML diagram of the multiton
@@types.each do |type, fruit| puts "#{type}"
end puts end def self.size @@types.size end end
In software engineering, the multiton pattern is a design
Fruit.get_fruit_by_type(“Banana”) Fruit.show_all
pattern similar to the singleton, which allows only one in-
Fruit.get_fruit_by_type(“Apple”) Fruit.show_all
stance of a class to be created. The multiton pattern ex-
Fruit.get_fruit_by_type(“Banana”) Fruit.show_all
pands on the singleton concept to manage a map of named
instances as key-value pairs.
Output:
Rather than having a single instance per application (e.g.
Number of instances made: 1 Banana Number of in- the java.lang.Runtime object in the Java programming
stances made: 2 Banana Apple Number of instances language) the multiton pattern instead ensures a single in-
made: 2 Banana Apple stance per key.
Most people and textbooks consider this a singleton pat-
2.5.3 See also tern. For example, multiton does not explicitly appear
in the highly regarded object-oriented programming text-
• Double-checked locking book Design Patterns (it appears as a more flexible ap-
proach named registry of singletons).
• Lazy loading
• Proxy pattern 2.6.1 Description
• Singleton pattern
While it may appear that the multiton is no more than a
simple hash table with synchronized access there are two
2.5.4 References important distinctions. First, the multiton does not allow
clients to add mappings. Secondly, the multiton never re-
[1] https://books.google.com/books?id=Qt-bRFetWw0C& turns a null or empty reference; instead, it creates and
lpg=PA30&ots=hW9ax5LeHb&dq=scala%20lazy% stores a multiton instance on the first request with the as-
20variables&pg=PA30#v=onepage&q=scala%20lazy% sociated key. Subsequent requests with the same key re-
20variables&f=false turn the original instance. A hash table is merely an im-
plementation detail and not the only possible approach.
The pattern simplifies retrieval of shared objects in an
2.5.5 External links application.
• Article "Java Tip 67: Lazy instantiation - Balancing Since the object pool is created only once, being a mem-
performance and resource usage” by Philip Bishop ber associated with the class (instead of the instance), the
and Nigel Warren multiton retains its flat behavior rather than evolving into
a tree structure.
• Java code examples
The multiton is unique in that it provides centralized ac-
• Use Lazy Initialization to Conserve Resources cess to a single directory (i.e. all keys are in the same
20 CHAPTER 2. CREATIONAL PATTERNS

namespace, per se) of multitons, where each multiton in-
stance in the pool may exist having its own state. In this
manner, the pattern advocates indexed storage of essen-
tial objects for the system (such as would be provided by
an LDAP system, for example). However, a multiton is
limited to wide use by a single system rather than a myr-
iad of distributed systems.
Object pools are primarily used for performance: in some
circumstances, object pools significantly improve perfor-
mance. Object pools complicate object lifetime, as ob-
jects obtained from and returned to a pool are not actually
created or destroyed at this time, and thus require care in
implementation.

2.7.1 Description
2.6.2 Drawbacks
When it is necessary to work with a large number of
This pattern, like the Singleton pattern, makes unit testing objects that are particularly expensive to instantiate and
far more difficult,[1] as it introduces global state into an each object is only needed for a short period of time, the
application. performance of an entire application may be adversely
affected. An object pool design pattern may be deemed
With garbage collected languages it may become a source
desirable in cases such as these.
of memory leaks as it introduces global strong references
to the objects. The object pool design pattern creates a set of objects
that may be reused. When a new object is needed, it is re-
quested from the pool. If a previously prepared object is
2.6.3 Implementations available it is returned immediately, avoiding the instan-
tiation cost. If no objects are present in the pool, a new
In Java, the multiton pattern can be implemented using an item is created and returned. When the object has been
enumerated type, with the values of the type correspond- used and is no longer needed, it is returned to the pool,
ing to the instances. In the case of an enumerated type allowing it to be used again in the future without repeat-
with a single value, this gives the singleton pattern. ing the computationally expensive instantiation process.
It is important to note that once an object has been used
and returned, existing references will become invalid.
2.6.4 References In some object pools the resources are limited so a max-
imum number of objects is specified. If this number is
[1] http://googletesting.blogspot.com/2008/11/ reached and a new item is requested, an exception may
clean-code-talks-global-state-and.html be thrown, or the thread will be blocked until an object
is released back into the pool.

2.6.5 External links The object pool design pattern is used in several places
in the standard classes of the .NET framework. One ex-
• Multiton implementation in Ruby language ample is the .NET Framework Data Provider for SQL
Server. As SQL Server database connections can be slow
• Multiton usage in PureMVC Framework for Action- to create, a pool of connections is maintained. When you
Script 3 close a connection it does not actually relinquish the link
to SQL Server. Instead, the connection is held in a pool
• Article with a C# Multiton implementation, example from which it can be retrieved when requesting a new con-
of use, and discussion of memory issues nection. This substantially increases the speed of making
connections.

2.7 Object pool pattern 2.7.2 Benefits

For the article about a general pool, see Pool (computer Object pooling can offer a significant performance boost
science). in situations where the cost of initializing a class instance
is high and the rate of instantiation and destruction of
The object pool pattern is a software creational design a class is high – in this case objects can frequently be
pattern that uses a set of initialized objects kept ready reused, and each reuse saves a significant amount of time.
to use – a "pool" – rather than allocating and destroy- Object pooling requires resources – memory and possi-
ing them on demand. A client of the pool will request bly other resources, such as network sockets, and thus it
an object from the pool and perform operations on the is preferable that the number of instances in use at any
returned object. When the client has finished, it returns one time is low, but this is not required.
the object to the pool rather than destroying it; this can The pooled object is obtained in predictable time when
be done manually or automatically. creation of the new objects (especially over network) may
2.7. OBJECT POOL PATTERN 21

take variable time. These benefits are mostly true for be in some state that was unexpected by the client pro-
objects that are expensive with respect to time, such as gram and may cause the client program to fail. The pool
database connections, socket connections, threads and is responsible for resetting the objects, not the clients.
large graphic objects like fonts or bitmaps. Object pools full of objects with dangerously stale state
In other situations, simple object pooling (that hold no are sometimes called object cesspools and regarded as an
external resources, but only occupy memory) may not be anti-pattern.
efficient and could decrease performance.[1] In case of The presence of stale state is not always an issue; it be-
simple memory pooling, the slab allocation memory man- comes dangerous when the presence of stale state causes
agement technique is more suited, as the only goal is to the object to behave differently. For example, an ob-
minimize the cost of memory allocation and deallocation ject that represents authentication details may break if the
by reducing fragmentation. “successfully authenticated” flag is not reset before it is
passed out, since it will indicate that a user is correctly au-
thenticated (possibly as someone else) when they haven't
2.7.3 Implementation yet attempted to authenticate. However, it will work just
fine if you fail to reset some value only used for debug-
Object pools can be implemented in an automated fash- ging, such as the identity of the last authentication server
ion in languages like C++ via smart pointers. In the used.
constructor of the smart pointer, an object can be re-
quested from the pool, and in the destructor of the smart Inadequate resetting of objects may also cause an infor-
pointer, the object can be released back to the pool. In mation leak. If an object contains confidential data (e.g.
garbage-collected languages, where there are no destruc- a user’s credit card numbers) that isn't cleared before the
tors (which are guaranteed to be called as part of a stack object is passed to a new client, a malicious or buggy
unwind), object pools must be implemented manually, by client may disclose the data to an unauthorized party.
explicitly requesting an object from the factory and re- If the pool is used by multiple threads, it may need the
turning the object by calling a dispose method (as in the means to prevent parallel threads from grabbing and try-
dispose pattern). Using a finalizer to do this is not a good ing to reuse the same object in parallel. This is not nec-
idea, as there are usually no guarantees on when (or if) essary if the pooled objects are immutable or otherwise
the finalizer will be run. Instead, “try ... finally” should thread-safe.
be used to ensure that getting and releasing the object is
exception-neutral.
Manual object pools are simple to implement, but harder 2.7.6 Criticism
to use, as they require manual memory management of
pool objects. Some publications do not recommend using object pool-
ing with certain languages, such as Java, especially for
objects that only use memory and hold no external
2.7.4 Handling of empty pools resources.[2] Opponents usually say that object allocation
is relatively fast in modern languages with garbage col-
Object pools employ one of three strategies to handle a lectors; while the operator new needs only ten instruc-
request when there are no spare objects in the pool. tions, the classic new - delete pair found in pooling de-
signs requires hundreds of them as it does more complex
1. Fail to provide an object (and return an error to the work. Also, most garbage collectors scan “live” object
client). references, and not the memory that these objects use for
their content. This means that any number of “dead” ob-
2. Allocate a new object, thus increasing the size of the jects without references can be discarded with little cost.
pool. Pools that do this usually allow you to set the In contrast, keeping a large number of “live” but unused
high water mark (the maximum number of objects objects increases the duration of garbage collection.[1]
ever used).
3. In a multithreaded environment, a pool may block
the client until another thread returns an object to 2.7.7 Examples
the pool.
C#

2.7.5 Pitfalls In the .NET Base Class Library there are a

When writing an object pool, the programmer has to be
careful to make sure the state of the objects returned to
the pool is reset back to a sensible state for the next use of
the object. If this is not observed, the object will often
few objects that implement this pattern. Sys-
tem.Threading.ThreadPool is configured to have a
predefined number of threads to allocate. When the
threads are returned, they are available for another
computation. Thus, one can use threads without paying
22 CHAPTER 2. CREATIONAL PATTERNS

the cost of creation and disposal of threads. the tasks can be placed in the queue. Finally, if this
The following shows the basic code of the object pool queue may get too long, it can be configured to suspend
design pattern implemented using C#. For brevity the the requesting thread.
properties of the classes are declared using C# 3.0 au- public class PooledObject { public String temp1; public
tomatically implemented property syntax. These could String temp2; public String temp3; public String get-
be replaced with full property definitions for earlier ver- Temp1() { return temp1; } public void setTemp1(String
sions of the language. Pool is shown as a static class, as temp1) { this.temp1 = temp1; } public String getTemp2()
it’s unusual for multiple pools to be required. However, { return temp2; } public void setTemp2(String temp2)
it’s equally acceptable to use instance classes for object { this.temp2 = temp2; } public String getTemp3() {
pools. return temp3; } public void setTemp3(String temp3) {
namespace DesignPattern.Objectpool { // The Poole- this.temp3 = temp3; } }
dObject class is the type that is expensive or slow to public class PooledObjectPool { private static
instantiate, // or that has limited availability, so is to be long expTime = 60000;//6 seconds public static
held in the object pool. public class PooledObject { HashMap<PooledObject, Long> available = new
DateTime _createdAt = DateTime.Now; public Date- HashMap<PooledObject, Long>(); public static
Time CreatedAt { get { return _createdAt; } } public HashMap<PooledObject, Long> inUse = new
string TempData { get; set; } } // The Pool class is the HashMap<PooledObject, Long>(); public synchro-
most important class in the object pool design pattern. nized static PooledObject getObject() { long now =
It controls access to the // pooled objects, maintaining System.currentTimeMillis(); if (available.isEmpty()) {
a list of available objects and a collection of objects PooledObject po = new PooledObject(); push(inUse, po,
that have already been // requested from the pool and now); return po; } else { for (Map.Entry<PooledObject,
are still in use. The pool also ensures that objects that Long> entry : available.entrySet()) { if (now -
have been released // are returned to a suitable state, entry.getValue() > expTime) { //object has ex-
ready for the next time they are requested. public pired popElement(available); } else { PooledOb-
static class Pool { private static List<PooledObject> ject po = popElement(available, entry.getKey());
_available = new List<PooledObject>(); pri- cleanUp(po); push(inUse, po, now); return po; }
vate static List<PooledObject> _inUse = new } } return null; } private synchronized static void
List<PooledObject>(); public static PooledObject push(HashMap<PooledObject, Long> map, PooledOb-
GetObject() { lock(_available) { if (_available.Count != ject po, long now) { map.put(po, now); } public static
void releaseObject(PooledObject po) { cleanUp(po);
0) { PooledObject po = _available[0]; _inUse.Add(po);
_available.RemoveAt(0); return po; } else { PooledOb- available.put(po, System.currentTimeMillis());
inUse.remove(po); } public static PooledOb-
ject po = new PooledObject(); _inUse.Add(po);
return po; } } } public static void ReleaseOb- ject popElement(HashMap<PooledObject, Long>
map) { Map.Entry<PooledObject, Long> entry
ject(PooledObject po) { CleanUp(po); lock (_available)
{ _available.Add(po); _inUse.Remove(po); } } private = map.entrySet().iterator().next(); PooledObject
key= entry.getKey(); //Long value=entry.getValue();
static void CleanUp(PooledObject po) { po.TempData =
null; } } } map.remove(entry.getKey()); return key; } public static
PooledObject popElement(HashMap<PooledObject,
Long> map, PooledObject key) { map.remove(key);
In the code above, the PooledObject includes two prop- return key; } public static void cleanUp(PooledObject
erties that are not shown in the UML diagram. One holds po) { po.setTemp1(null); po.setTemp2(null);
the time at which the object was first created. The other po.setTemp3(null); } }
holds a string that can be modified by the client but that is
reset when the PooledObject is released back to the pool.
This shows the clean-up process on release of an object
that ensures it is in a valid state before it can be requested 2.7.8 See also
from the pool again.
• Connection pool
• Free list
Java
• Slab allocation
Java supports thread pooling via
java.util.concurrent.ExecutorService and other re-
2.7.9 References
lated classes. The executor service has a certain number
of “basic” threads that are never discarded. If all threads [1] Goetz, Brian (2005-09-27). “Java theory and practice:
are busy, the service allocates the allowed number of Urban performance legends, revisited”. IBM developer-
extra threads that are later discarded if not used for the Works. Archived from the original on 2005-09-27. Re-
certain expiration time. If no more threads are allowed, trieved 2012-08-28.
2.8. PROTOTYPE PATTERN 23

[2] Goetz, Brian (2005-09-27). “Java theory and practice: The mitotic division of a cell — resulting in two identical
Garbage collection in the HotSpot JVM”. IBM devel- cells — is an example of a prototype that plays an active
operWorks. Archived from the original on 2003-11-25. role in copying itself and thus, demonstrates the Proto-
Retrieved 2012-08-28. type pattern. When a cell splits, two cells of identical
genotype result. In other words, the cell clones itself.[1]
• Kircher, Michael; Prashant Jain (2002-07-04).
“Pooling Pattern” (PDF). EuroPLoP 2002. Ger-
many. Retrieved 2007-06-09. 2.8.1 Structure
• Goldshtein, Sasha; Zurbalev, Dima; Flatow, Ido
(2012). Pro .NET Performance: Optimize Your C# I
«interface»
Prototype «import»
Client

Applications. Apress. ISBN 978-1-4302-4458-5. clone()

operation()

Object p = prototype.clone();

2.7.10 External links

ConcretePrototype1 ConcretePrototype2

clone() clone()

• OODesign article return copy of self return copy of self

• Improving Performance with Object Pooling (Mi-

crosoft Developer Network ) UML class diagram describing the prototype design pattern

• Developer.com article
• Portland Pattern Repository entry
2.8.2 Rules of thumb
• Apache Commons Pool: A mini-framework to cor-
rectly implement object pooling in Java Sometimes creational patterns overlap — there are cases
when either prototype or abstract factory would be appro-
• Game Programming Patterns: Object Pool
priate. At other times they complement each other: ab-
stract factory might store a set of prototypes from which
to clone and return product objects (GoF, p126). Ab-
2.8 Prototype pattern stract factory, builder, and prototype can use singleton in
their implementations. (GoF, p81, 134). Abstract fac-
For other uses, see Software prototyping. tory classes are often implemented with factory meth-
Not to be confused with Prototype-based programming ods (creation through inheritance), but they can be im-
or Function prototype. plemented using prototype (creation through delegation).
(GoF, p95)
The prototype pattern is a creational design pattern in Often, designs start out using Factory Method (less com-
software development. It is used when the type of objects plicated, more customizable, subclasses proliferate) and
to create is determined by a prototypical instance, which evolve toward abstract factory, prototype, or builder
is cloned to produce new objects. This pattern is used to: (more flexible, more complex) as the designer discovers
where more flexibility is needed. (GoF, p136)
• avoid subclasses of an object creator in the client ap- Prototype does not require subclassing, but it does require
plication, like the abstract factory pattern does. an “initialize” operation. Factory method requires sub-
• avoid the inherent cost of creating a new object in the classing, but does not require initialization. (GoF, p116)
standard way (e.g., using the 'new' keyword) when it Designs that make heavy use of the composite and
is prohibitively expensive for a given application. decorator patterns often can benefit from Prototype as
well. (GoF, p126)
To implement the pattern, declare an abstract base class The rule of thumb could be that you would need to clone()
that specifies a pure virtual clone() method. Any class an Object when you want to create another Object at run-
that needs a "polymorphic constructor" capability derives time that is a true copy of the Object you are cloning. True
itself from the abstract base class, and implements the copy means all the attributes of the newly created Object
clone() operation. should be the same as the Object you are cloning. If you
The client, instead of writing code that invokes the “new” could have instantiated the class by using new instead, you
operator on a hard-coded class name, calls the clone() would get an Object with all attributes as their initial val-
method on the prototype, calls a factory method with ues. For example, if you are designing a system for per-
a parameter designating the particular concrete derived forming bank account transactions, then you would want
class desired, or invokes the clone() method through some to make a copy of the Object that holds your account in-
mechanism provided by another design pattern. formation, perform transactions on it, and then replace
24 CHAPTER 2. CREATIONAL PATTERNS

the original Object with the modified one. In such cases, 2.8.5 Java Example
you would want to use clone() instead of new.
This pattern creates the kind of object using its prototype.
In other words, while creating the object of Prototype ob-
ject, the class actually creates a clone of it and returns it as
2.8.3 Pseudocode prototype. You can see here, we have used Clone method
to clone the prototype when required.
Let’s write an occurrence browser class for a text. This // Prototype pattern public abstract class Prototype
class lists the occurrences of a word in a text. Such an implements Cloneable { public Prototype clone() throws
object is expensive to create as the locations of the occur-CloneNotSupportedException{ return (Prototype) su-
rences need an expensive process to find. So, to duplicate per.clone(); } } public class ConcretePrototype1 extends
such an object, we use the prototype pattern: Prototype { @Override public Prototype clone() throws
CloneNotSupportedException { return super.clone(); }
class WordOccurrences is field occurrences is The list } public class ConcretePrototype2 extends Prototype {
of the index of each occurrence of the word in the text. @Override public Prototype clone() throws CloneNot-
constructor WordOccurrences(text, word) is input: the SupportedException { return super.clone(); } }
text in which the occurrences have to be found input:
the word that should appear in the text Empty the oc-
currences list for each textIndex in text isMatching :=
true for each wordIndex in word if the current word 2.8.6 PHP Example
character does not match the current text character then
isMatching := false if isMatching is true then Add the // The Prototype pattern in PHP is done with the
current textIndex into the occurrences list method getO- use of built-in PHP function __clone() abstract class
neOccurrenceIndex(n) is input: a number to point on Prototype { public $a; public $b; public function
the nth occurrence. output: the index of the nth occur- displayCONS() { echo “CONS: {$this->a}\n"; echo
rence. Return the nth item of the occurrences field if any. “CONS: {$this->b}\n"; } public function display-
method clone() is output: a WordOccurrences object CLON() { echo “CLON: {$this->a}\n"; echo “CLON:
containing the same data. Call clone() on the super class. {$this->b}\n"; } abstract function __clone(); } class
On the returned object, set the occurrences field with the ConcretePrototype1 extends Prototype { public function
value of the local occurrences field. Return the cloned ob- __construct() { $this->a = “A1"; $this->b = “B1";
ject. text := “The prototype pattern is a creational design $this->displayCONS(); } function __clone() { $this-
pattern in software development first described in design >displayCLON(); } } class ConcretePrototype2 extends
patterns, the book.” word := “pattern"d searchEngine := Prototype { public function __construct() { $this->a
new WordOccurrences(text, word) anotherSearchEngine = “A2"; $this->b = “B2"; $this->displayCONS(); }
:= searchEngine.clone() function __clone() { $this->a = $this->a ."-C"; $this->b
(the search algorithm is not optimized; it is a basic algo- = $this->b ."-C"; $this->displayCLON(); } } $cP1 =
rithm to illustrate the pattern implementation) new ConcretePrototype1(); $cP2 = new ConcreteProto-
type2(); $cP2C = clone $cP2; // RESULT: #quanton81
// CONS: A1 // CONS: B1 // CONS: A2 // CONS: B2 //
CLON: A2-C // CLON: B2-C
2.8.4 C# Example

This pattern creates the kind of object using its prototype. 2.8.7 See also
In other words, while creating the object of Prototype ob-
ject, the class actually creates a clone of it and returns it • Function prototype
as prototype.You can see here, we have used Member-
wiseClone method to clone the prototype when required.
2.8.8 References
public abstract class Prototype { // normal imple-
mentation public abstract Prototype Clone(); } [1] Duell, Michael (July 1997). “Non-Software Examples of
public class ConcretePrototype1 : Prototype { Design Patterns”. Object Magazine. 7 (5): 54. ISSN 1055-
public override Prototype Clone() { return (Proto- 3614.
type)this.MemberwiseClone(); // Clones the concrete
class. } } public class ConcretePrototype2 : Prototype
{ public override Prototype Clone() { return (Proto- 2.8.9 Sources
type)this.MemberwiseClone(); // Clones the concrete
class. } } • Gamma, Erich; Helm, Richard; Johnson, Ralph;
Vlissides, John (1994). Design Patterns: Elements
2.9. RESOURCE ACQUISITION IS INITIALIZATION 25

of Reusable Object-Oriented Software. Addison- all stack objects are destroyed at the end of the enclos-
Wesley. ISBN 0-201-63361-2. ing scope, known as stack unwinding. The destructors of
both the lock and file objects are therefore guaranteed to
be called when returning from the function, whether an
2.9 Resource Acquisition Is Initial- exception has been thrown or not.[9]
ization Local variables allow easy management of multiple re-
sources within a single function: they are destroyed in the
reverse order of their construction, and an object is de-
Resource acquisition is initialization (RAII)[1] is a stroyed only if fully constructed—that is, if no exception
programming idiom[2] used in several object-oriented propagates from its constructor.[10]
languages, most prominently C++, where it originated,
but also D, Ada, Vala, and Rust. The technique was Using RAII greatly simplifies resource management, re-
developed for exception-safe resource management in duces overall code size and helps ensure program correct-
C++[3] during 1984–89, primarily by Bjarne Stroustrup ness. RAII is therefore highly recommended in C++, and
[11]
and Andrew Koenig,[4] and the term itself was coined most of the C++ standard library follows the idiom.
by Stroustrup.[5] RAII is generally pronounced as an
initialism, sometimes pronounced as “R, A, double I”.[6]
2.9.2 Benefits
In RAII, holding a resource is a class invariant, and is tied
to object lifetime: resource allocation (or acquisition) is The advantages of RAII as a resource management tech-
done during object creation (specifically initialization), by nique are that it provides encapsulation, exception safety
the constructor, while resource deallocation (release) is (for stack resources), and locality (it allows acquisition
done during object destruction (specifically finalization), and release logic to be written next to each other).
by the destructor. Thus the resource is guaranteed to be
Encapsulation is provided because resource management
held between when initialization finishes and finalization
logic is defined once in the class, not at each call site. Ex-
starts (holding the resources is a class invariant), and to
ception safety is provided for stack resources (resources
be held only when the object is alive. Thus if there are no
that are released in the same scope as they are acquired)
object leaks, there are no resource leaks.
by tying the resource to the lifetime of a stack variable (a
Other names for this idiom include Constructor Ac- local variable declared in a given scope): if an exception
quires, Destructor Releases (CADRe) [7] and one partic- is thrown, and proper exception handling is in place, the
ular style of use is called Scope-based Resource Manage- only code that will be executed when exiting the cur-
ment (SBRM).[8] This latter term is for the special case rent scope are the destructors of objects declared in that
of automatic variables. RAII ties resources to object life- scope. Finally, locality of definition is provided by writ-
time, which may not coincide with entry and exit of a ing the constructor and destructor definitions next to each
scope. (Notably variables allocated on the free store have other in the class definition.
lifetimes unrelated to any given scope.) However, using
Resource management therefore needs to be tied to the
RAII for automatic variables (SBRM) is the most com-
lifespan of suitable objects in order to gain automatic al-
mon use case.
location and reclamation. Resources are acquired during
initialization, when there is no chance of them being used
2.9.1 C++11 example before they are available, and released with the destruc-
tion of the same objects, which is guaranteed to take place
The following C++11 example demonstrates usage of even in case of errors.
RAII for file access and mutex locking: Comparing RAII with the finally construct used in Java,
#include <mutex> #include <iostream> #include Stroustrup wrote that “In realistic systems, there are far
<string> #include <fstream> #include <stdexcept> more resource acquisitions than kinds of resources, so the
void write_to_file (const std::string & message) { // “resource acquisition is initialization” technique leads to
mutex to protect file access (shared across threads) static less code than use of a “finally” construct.”[1]
std::mutex mutex; // lock mutex before accessing file
std::lock_guard<std::mutex> lock(mutex); // try to open
2.9.3 Typical uses
file std::ofstream file(“example.txt”); if (!file.is_open())
throw std::runtime_error(“unable to open file”); // writeThe RAII design is often used for controlling mutex locks
message to file file << message << std::endl; // file will be
in multi-threaded applications. In that use, the object re-
closed 1st when leaving scope (regardless of exception) leases the lock when destroyed. Without RAII in this sce-
// mutex will be unlocked 2nd (from lock destructor) nario the potential for deadlock would be high and the
when leaving // scope (regardless of exception) } logic to lock the mutex would be far from the logic to
unlock it. With RAII, the code that locks the mutex es-
This code is exception-safe because C++ guarantees that sentially includes the logic that the lock will be released
26
when execution leaves the scope of the RAII object.
Another typical example is interacting with files: We
could have an object that represents a file that is open
for writing, wherein the file is opened in the constructor
and closed when execution leaves the object’s scope. In
both cases, RAII ensures only that the resource in ques-
tion is released appropriately; care must still be taken to
maintain exception safety. If the code modifying the data
structure or file is not exception-safe, the mutex could be
unlocked or the file closed with the data structure or file
corrupted.
Ownership of dynamically allocated objects (memory
allocated with new in C++) can also be controlled
with RAII, such that the object is released when the
RAII (stack-based) object is destroyed. For this pur-
pose, the C++11 standard library defines the smart
pointer classes std::unique_ptr for single-owned objects
and std::shared_ptr for objects with shared ownership.
Similar classes are also available through std::auto_ptr in
C++98, and boost::shared_ptr in the Boost libraries.
2.9.4 Clang and GCC “cleanup” extension However, object lifetimes are not necessarily bound
to any scope, and objects may be destroyed non-
for C
Both Clang and GNU Compiler Collection implement
a non-standard extension to the C language to support
RAII: the “cleanup” variable attribute.[12] The following
macro annotates a variable with a given destructor func-
tion that it will call when the variable goes out of scope:
static inline void fclosep(FILE **fp) { if (*fp)
fclose(*fp); } #define _cleanup_fclose_ __at-
tribute__((cleanup(fclosep)))
This macro can then be used as follows:
void example_usage() { _cleanup_fclose_ FILE *logfile
= fopen(“logfile.txt”, “w+"); fputs(“hello logfile!", log-
file); }
In this example, the compiler arranges for the fclosep
function to be called before example_usage returns.
2.9.5 Limitations
RAII only works for resources acquired and released (di-
rectly or indirectly) by stack-allocated objects, where
there is a well-defined static object lifetime. Heap-
allocated objects which themselves acquire and release
resources are common in many languages, including
C++. RAII depends on heap-based objects to be im-
plicitly or explicitly deleted along all possible execution
paths, in order to trigger its resource-releasing destruc-
tor (or equivalent).[13]:8:27 This can be achieved by using
smart pointers to manage all heap objects, with weak-
pointers for cyclically referenced objects.
CHAPTER 2. CREATIONAL PATTERNS
In C++, stack unwinding is only guaranteed to occur if
the exception is caught somewhere. This is because “If
no matching handler is found in a program, the function
terminate() is called; whether or not the stack is unwound
before this call to terminate() is implementation-defined
(15.5.1).” (C++03 standard, §15.3/9).[14] This behavior
is usually acceptable, since the operating system releases
remaining resources like memory, files, sockets, etc. at
program termination.
2.9.6 Reference counting
Perl, Python (in the CPython implementation),[15] and
PHP[16] manage object lifetime by reference counting,
which makes it possible to use RAII. Objects that are
no longer referenced are immediately destroyed or final-
ized and released, so a destructor or finalizer can release
the resource at that time. However, it is not always id-
iomatic in such languages, and is specifically discouraged
in Python (in favor of context managers and finalizers
from the weakref package).
deterministically or not at all. This makes it possible
to accidentally leak resources that should have been re-
leased at the end of some scope. Objects stored in a
static variable (notably a global variable) may not be fi-
nalized when the program terminates, so their resources
are not released; CPython makes no guarantee of fi-
nalizing such objects, for instance. Further, objects
with circular references will not be collected by a sim-
ple reference counter, and will live indeterminately long;
even if collected (by more sophisticated garbage collec-
tion), destruction time and destruction order will be non-
deterministic. In CPython there is a cycle detector which
detects cycles and finalizes the objects in the cycle, though
prior to CPython 3.4, cycles are not collected if any ob-
ject in the cycle has a finalizer.[17] Also, in the case of
Python, the garbage collection strategy is an implementa-
tion detail, so running with an alternative interpreter (such
as IronPython or Jython) could result in the RAII imple-
mentation not working.
2.9.7 References
[1] Bjarne Stroustrup Why doesn't C++ provide a “finally”
construct? Accessed on 2013-01-02.
[2] Sutter, Herb; Alexandrescu, Andrei (2005). C++ Coding
Standards. C++ In-Depth Series. Addison-Wesley. p. 24.
ISBN 0-321-11358-6.
[3] Stroustrup 1994, 16.5 Resource Management, pp. 388–
89.
[4] Stroustrup 1994, 16.1 Exception Handling: Introduction,
pp. 383–84.
2.10. SINGLETON PATTERN 27

[5] Stroustrup 1994, p. 389. I called this technique “resource

acquisition is initialization.”

[6] "How do you pronounce RAII?", StackOverflow Singleton

[7] https://groups.google.com/a/isocpp.org/forum/#!topic/ - singleton : Singleton

std-proposals/UnarLCzNPcI
- Singleton()
[8] http://allenchou.net/2014/10/ + getInstance() : Singleton
scope-based-resource-management-raii/

[9] “dtors-shouldnt-throw”. Retrieved 12 February 2013.

[10] “What’s the order that local objects are destructed?". Re- Class diagram exemplifying the singleton pattern.
trieved 12 February 2013.

[11] “too-many-trycatch-blocks”. C++ FAQ. Archived from

the original on 1 November 2014. Retrieved 4 June 2014.
[12] https://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.software design pattern that restricts the instantiation of a
html
[13] Weimer, W; Nebula, G.C. (2008). “Exceptional Situa- concept is sometimes generalized to systems that oper-
tions and Program Reliability” (PDF). ACM Transactions
on Programming Languages and Systems, vol 30 (2).
[14] “RAII and Stack unwinding”. 2011.
[15] Extending Python with C or C++: Reference Counts
[16] https://stackoverflow.com/a/4938780
[17] gc — Garbage Collector interface
2.9.8 Further reading
• Stroustrup, Bjarne (1994). The Design and Evolu-
tion of C++. Addison-Wesley. ISBN 0-201-54330-
3.
2.9.9 External links
• Sample Chapter "Gotcha #67: Failure to Employ
Resource Acquisition Is Initialization" by Stephen
Dewhurst
• Interview "A Conversation with Bjarne Stroustrup"
by Bill Venners
• Article "The Law of The Big Two" by Bjorn Karls-
son and Matthew Wilson
• Article "Implementing the 'Resource Acquisition is
Initialization' Idiom" by Danny Kalev
• Article "RAII, Dynamic Objects, and Factories in
C++" by Roland Pibinger An implementation of the singleton pattern must:
2.10 Singleton pattern
In software engineering, the singleton pattern is a
class to one object. This is useful when exactly one object
is needed to coordinate actions across the system. The
ate more efficiently when only one object exists, or that
restrict the instantiation to a certain number of objects.
The term comes from the mathematical concept of a sin-
gleton.
There are some who are critical of the singleton pattern
and consider it to be an anti-pattern in that it is frequently
used in scenarios where it is not beneficial, introduces un-
necessary restrictions in situations where a sole instance
of a class is not actually required, and introduces global
state into an application.[1][2][3]
2.10.1 Common uses
• The abstract factory, builder, and prototype patterns
can use Singletons in their implementation.
• Facade objects are often singletons because only one
Facade object is required.
• State objects are often singletons.
• Singletons are often preferred to global variables be-
cause:
• They do not pollute the global namespace (or,
in languages with namespaces, their containing
namespace) with unnecessary variables.[4]
• They permit lazy allocation and initialization,
whereas global variables in many languages
will always consume resources.
2.10.2 Implementation

• RAII in Delphi "One-liner RAII in Delphi" by Barry • ensure that only one instance of the singleton class
Kelly ever exists; and
28 CHAPTER 2. CREATIONAL PATTERNS

• provide global access to that instance. 2.10.5 External links

• Complete article "Singleton Design Pattern tech-
Typically, this is done by:
niques"

• declaring all constructors of the class to be private; • Four different ways to implement singleton in Java
and "Ways to implement singleton in Java"

• providing a static method that returns a reference to • Book extract: Implementing the Singleton Pattern
the instance. in C# by Jon Skeet

• Singleton at Microsoft patterns & practices Devel-

The instance is usually stored as a private static variable;
the instance is created when the variable is initialized, at
some point before the static method is first called. The
following is a sample implementation written in Java.
public final class Singleton { private static final Singleton
INSTANCE = new Singleton(); private Singleton()
{} public static Singleton getInstance() { return IN-
STANCE; } }
oper Center
• IBM article "Double-checked locking and the Sin-
gleton pattern" by Peter Haggar
• IBM article "Use your singletons wisely" by J. B.
Rainsberger
• Javaworld article "Simply Singleton" by David
Geary
• Google article "Why Singletons Are Controversial"

Lazy initialization • Google Singleton Detector (analyzes Java bytecode

to detect singletons)
A singleton implementation may use lazy initialization,
where the instance is created when the static method is
first invoked. If the static method might be called from
multiple threads simultaneously, measures may need to
be taken to prevent race conditions that could result in
the creation of multiple instances of the class. The fol-
lowing is a thread-safe sample implementation, using
lazy initialization with double-checked locking, written
in Java.[lower-alpha 1]
public final class Singleton { private static volatile
Singleton instance = null; private Singleton() {} public
static Singleton getInstance() { if (instance == null) {
synchronized(Singleton.class) { if (instance == null) {
instance = new Singleton(); } } } return instance; } }

2.10.3 Notes
[1] In Java, to avoid the synchronization overhead while keep-
ing lazy initialization with thread safety, the preferred ap-
proach is to use the initialization-on-demand holder idiom.

2.10.4 References
[1] Scott Densmore. Why singletons are evil, May 2004

[2] Steve Yegge. Singletons considered stupid, September

2004

[3] Clean Code Talks - Global State and Singletons

[4] Gamma, E, Helm, R, Johnson, R, Vlissides, J: “Design

Patterns”, page 128. Addison-Wesley, 1995
Chapter 3

Structural patterns

3.1 Structural pattern • Proxy pattern: a class functioning as an interface to

another thing
In software engineering, structural design patterns are
design patterns that ease the design by identifying a simple
way to realize relationships between entities. 3.1.1 See also
Examples of Structural Patterns include:
• Behavioral pattern
• Adapter pattern: 'adapts’ one interface for a class
into one that a client expects • Concurrency pattern

• Adapter pipeline: Use multiple adapters for • Creational pattern

debugging purposes.[1]
• Retrofit Interface Pattern:[2][3] An adapter
used as a new interface for multiple classes at
3.1.2 References
the same time.
• Aggregate pattern: a version of the Composite pat- [1] “Adapter Pipeline”. Cunningham & Cunningham, Inc.
tern with methods for aggregation of children 2010-12-31. Archived from the original on 2010-12-31.
Retrieved 2012-07-20.
• Bridge pattern: decouple an abstraction from its im-
plementation so that the two can vary independently [2] BobbyWoolf (2002-06-19). “Retrofit Interface Pattern”.
Cunningham & Cunningham, Inc. Archived from the
• Tombstone: An intermediate “lookup” object
original on 2002-06-19. Retrieved 2012-07-20.
contains the real location of an object.[4]
• Composite pattern: a tree structure of objects where [3] MartinZarate (2010-12-31). “External Polymorphism”.
every object has the same interface Cunningham & Cunningham, Inc. Archived from the
original on 2010-12-31. Retrieved 2012-07-20.
• Decorator pattern: add additional functionality to a
class at runtime where subclassing would result in an [4] “Tomb Stone”. Cunningham & Cunningham, Inc. 2007-
exponential rise of new classes 06-17. Archived from the original on 2007-06-17. Re-
trieved 2012-07-20.
• Extensibility pattern: a.k.a. Framework - hide com-
plex code behind a simple interface
• Facade pattern: create a simplified interface of an
existing interface to ease usage for common tasks 3.2 Adapter pattern
• Flyweight pattern: a large quantity of objects share In software engineering, the adapter pattern is a
a common properties object to save space software design pattern (also known as Wrapper, an al-
• Marker pattern: an empty interface to associate ternative naming shared with the Decorator pattern) that
metadata with a class. allows the interface of an existing class to be used as an-
other interface.[1] It is often used to make existing classes
• Pipes and filters: a chain of processes where the out- work with others without modifying their source code.
put of each process is the input of the next
An example is an adapter that converts the interface of
• Opaque pointer: a pointer to an undeclared or pri- a Document Object Model of an XML document into a
vate type, to hide implementation details tree structure that can be displayed.

29
30
3.2.1 Definition
An adapter helps two incompatible interfaces to work to-
gether. This is the real world definition for an adapter.
Interfaces may be incompatible, but the inner function-
ality should suit the need. The Adapter design pattern
allows otherwise incompatible classes to work together
by converting the interface of one class into an interface
expected by the clients.
3.2.2 Usage
An adapter can be used when the wrapper must respect a
particular interface and must support polymorphic behav-
ior. Alternatively, a decorator makes it possible to add or
alter behavior of an interface at run-time, and a Facade is
used when an easier or simpler interface to an underlying
object is desired.[2]
3.2.3 Structure
There are two adapter patterns:[1]
Object Adapter pattern
In this adapter pattern, the adapter contains an instance
of the class it wraps. In this situation, the adapter makes
calls to the instance of the wrapped object.
The object adapter pattern expressed in UML. The adapter hides
the adaptee’s interface from the client.
The object adapter pattern.
CHAPTER 3. STRUCTURAL PATTERNS
Class Adapter pattern
This adapter pattern uses multiple polymorphic interfaces
implementing or inheriting both the interface that is ex-
pected and the interface that is pre-existing. It is typical
for the expected interface to be created as a pure interface
class, especially in languages such as Java (before jdk 1.8)
that do not support multiple inheritance of classes.[1]
The class adapter pattern expressed in UML.
The class adapter pattern expressed in LePUS3
A further form of runtime Adapter pattern
There is a further form of runtime adapter pattern as fol-
lows:
It is desired for classA to supply classB with some data,
let us suppose some String data. A compile time solution
is:
classB.setStringData(classA.getStringData());
However, suppose that the format of the string data must
be varied. A compile time solution is to use inheritance:
public class Format1ClassA extends ClassA { @Override
public String getStringData() { return format(toString());
}}
and perhaps create the correctly “formatting” object at
runtime by means of the Factory pattern.
A solution using “adapters” proceeds as follows:
(i) Define an intermediary “Provider” interface, and write
an implementation of that Provider interface that wraps
3.2. ADAPTER PATTERN 31

the source of the data, ClassA in this example, and out- (vii) In this way, the use of adapters and providers al-
puts the data formatted as appropriate: lows multiple “views” by ClassB and ClassC into ClassA
public interface StringProvider { public String getString- without having to alter the class hierarchy. In general,
Data(); } public class ClassAFormat1 implements String- it permits a mechanism for arbitrary data flows between
Provider { private ClassA classA = null; public Clas- objects that can be retrofitted to an existing object hier-
sAFormat1(final ClassA a) { classA = a; } public String archy.
getStringData() { return format(classA.getStringData());
} private String format(final String sourceValue) { //
Implementation of the Adapter pattern
Manipulate the source string into a format required //
by the object needing the source object’s data return
When implementing the adapter pattern, for
sourceValue.trim(); } }
clarity one can apply the class name [Class-
Name]To[Interface]Adapter to the provider implemen-
(ii) Write an Adapter class that returns the specific imple- tation, for example DAOToProviderAdapter. It should
mentation of the Provider: have a constructor method with an adaptee class variable
public class ClassAFormat1Adapter extends Adapter { as a parameter. This parameter will be passed to an
public Object adapt(final Object anObject) { return new instance member of [ClassName]To[Interface]Adapter.
ClassAFormat1((ClassA) anObject); } } When the clientMethod is called, it will have access
to the adaptee instance that allows for accessing the
required data of the adaptee and performing operations
(iii) Register the Adapter with a global registry, so that on that data that generates the desired output.
the Adapter can be looked up at runtime:
AdapterFactory.getInstance().registerAdapter(ClassA.class,
ClassAFormat1Adapter.class, “format1”); Crystal abstract class FormatIphone getter connector
abstract def recharge abstract def use_lightning end
abstract class FormatAndroid getter connector abstract
(iv) In code, when wishing to transfer data from ClassA def recharge abstract def use_micro_usb end class
to ClassB, write: Iphone < FormatIphone def initialize @connector = false
Adapter adapter = AdapterFactory.getInstance() end def use_lightning @connector = true puts “Light-
.getAdapterFromTo(ClassA.class, StringProvider.class, ning connected” end def recharge if @connector puts
“format1”); StringProvider provider = (String- “Recharge started” puts “Recharge finished” else puts
Provider) adapter.adapt(classA); String string = “Connect Lightning first” end end end class Android <
provider.getStringData(); classB.setStringData(string); FormatAndroid def initialize @connector = false end def
use_micro_usb @connector = true puts “MicroUsb con-
nected” end def recharge if @connector puts “Recharge
or more concisely: started” puts “Recharge finished” else puts “Connect
classB.setStringData( ((StringProvider) AdapterFac- MicroUsb first” end end end class IphoneAdapter < For-
tory.getInstance() .getAdapterFromTo(ClassA.class, matAndroid private getter mobile : FormatIphone def
StringProvider.class, “format1”) .adapt(classA)) .get- initialize(@mobile) end def recharge @mobile.recharge
StringData()); end def use_micro_usb puts “MicroUsb connected”
@mobile.use_lightning end end class AndroidRecharger
def initialize phone = Android.new phone.use_micro_usb
(v) The advantage can be seen in that, if it is desired to
phone.recharge end end class IphoneMicroUs-
transfer the data in a second format, then look up the dif-
bRecharger def initialize phone = Iphone.new
ferent adapter/provider:
phone_adapter = IphoneAdapter.new(phone)
Adapter adapter = AdapterFactory.getInstance() phone_adapter.use_micro_usb phone_adapter.recharge
.getAdapterFromTo(ClassA.class, StringProvider.class, end end class IphoneRecharger def initialize phone =
“format2”); Iphone.new phone.use_lightning phone.recharge end end
puts “Recharging android with MicroUsb Recharger”
(vi) And if it is desired to output the data from ClassA as, AndroidRecharger.new puts puts “Recharging iPhone
say, image data in Class C: with MicroUsb using Adapter pattern” IphoneMicroUs-
bRecharger.new puts puts “Recharging iPhone with
Adapter adapter = AdapterFactory.getInstance() iPhone Recharger” IphoneRecharger.new
.getAdapterFromTo(ClassA.class, Image-
Provider.class, “format2”); ImageProvider
provider = (ImageProvider) adapter.adapt(classA); Output
classC.setImage(provider.getImage()); Recharging android with MicroUsb Recharger Mi-
croUsb connected Recharge started Recharge finished
Recharging iPhone with MicroUsb using Adapter pat-
32
tern MicroUsb connected Lightning connected Recharge
started Recharge finished Recharging iPhone with
iPhone Recharger Lightning connected Recharge started
Recharge finished
Java public class AdapteeToClientAdapter imple-
ments Adapter { private final Adaptee instance; public
AdapteeToClientAdapter(final Adaptee instance) {
this.instance = instance; } @Override public void client-
Method() { // call Adaptee’s method(s) to implement
Client’s clientMethod } }
PHP // Adapter Pattern example interface IFormatI-
Phone { public function recharge(); public function
useLightning(); } interface IFormatAndroid { public
function recharge(); public function useMicroUsb();
} // Adaptee class IPhone implements IFormatIPhone
{ private $connectorOk = FALSE; public function
useLightning() { $this->connectorOk = TRUE; echo
“Lightning connected -$\n"; } public function recharge()
{ if($this->connectorOk) { echo “Recharge Started\n";
echo “Recharge 20%\n"; echo “Recharge 50%\n"; echo
“Recharge 70%\n"; echo “Recharge Finished\n"; } else
{ echo “Connect Lightning first\n"; } } } // Adapter class
IPhoneAdapter implements IFormatAndroid { private
$mobile; public function __construct(IFormatIPhone
$mobile) { $this->mobile = $mobile; } public func-
tion recharge() { $this->mobile->recharge(); } public
function useMicroUsb() { echo “MicroUsb con-
nected -> "; $this->mobile->useLightning(); } } class
Android implements IFormatAndroid { private $con-
nectorOk = FALSE; public function useMicroUsb()
{ $this->connectorOk = TRUE; echo “MicroUsb
connected ->\n"; } public function recharge() { if($this-
>connectorOk) { echo “Recharge Started\n"; echo
“Recharge 20%\n"; echo “Recharge 50%\n"; echo
“Recharge 70%\n"; echo “Recharge Finished\n"; }
else { echo “Connect MicroUsb first\n"; } } } // client
class MicroUsbRecharger { private $phone; private
$phoneAdapter; public function __construct() { echo "--
-Recharging iPhone with Generic Recharger---\n"; $this-
>phone = new IPhone(); $this->phoneAdapter = new
IPhoneAdapter($this->phone); $this->phoneAdapter-
>useMicroUsb(); $this->phoneAdapter->recharge();
echo "---iPhone Ready for use---\n\n"; } } $mi-
croUsbRecharger = new MicroUsbRecharger(); class
IPhoneRecharger { private $phone; public func-
tion __construct() { echo "---Recharging iPhone
with iPhone Recharger---\n"; $this->phone = new
IPhone(); $this->phone->useLightning(); $this->phone-
>recharge(); echo "---iPhone Ready for use---\n\n"; } }
$iPhoneRecharger = new IPhoneRecharger(); class An-
droidRecharger { public function __construct() { echo
"---Recharging Android Phone with Generic Recharger-
--\n"; $this->phone = new Android(); $this->phone-
>useMicroUsb(); $this->phone->recharge(); echo
CHAPTER 3. STRUCTURAL PATTERNS
"---Phone Ready for use---\n\n"; } } $androidRecharger
= new AndroidRecharger(); // Result: #quanton81
//---Recharging iPhone with Generic Recharger--- //Mi-
croUsb connected -> Lightning connected -$ //Recharge
Started //Recharge 20% //Recharge 50% //Recharge
70% //Recharge Finished //---iPhone Ready for use---
// //---Recharging iPhone with iPhone Recharger---
//Lightning connected -$ //Recharge Started //Recharge
20% //Recharge 50% //Recharge 70% //Recharge
Finished //---iPhone Ready for use--- // //---Recharging
Android Phone with Generic Recharger--- //MicroUsb
connected -> //Recharge Started //Recharge 20%
//Recharge 50% //Recharge 70% //Recharge Finished
//---Phone Ready for use---
Scala implicit def adaptee2Adapter(adaptee:
Adaptee): Adapter = { new Adapter { override def
clientMethod: Unit = { // call Adaptee’s method(s) to
implement Client’s clientMethod */ } } }
3.2.4 See also
• Delegation, strongly relevant to the object adapter
pattern.
• Dependency inversion principle, which can be
thought of as applying the Adapter pattern, when
the high-level class defines their own (adapter) in-
terface to the low-level module (implemented by an
Adaptee class).
• Shim
• Wrapper function
• Wrapper library
3.2.5 References
[1] Freeman, Eric; Freeman, Elisabeth; Kathy, Sierra; Bates,
Bert (2004). “Head First Design Patterns” (paperback).
O'Reilly Media: 244. ISBN 978-0-596-00712-6. OCLC
809772256. Retrieved April 30, 2013.
[2] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
“Head First Design Patterns” (paperback). 1. O'Reilly:
243, 252, 258, 260. ISBN 978-0-596-00712-6. Re-
trieved 2012-07-02.
3.3 Bridge pattern
The bridge pattern is a design pattern used in software
engineering that is meant to “decouple an abstraction from
its implementation so that the two can vary independently”,
3.3. BRIDGE PATTERN 33

introduced by the Gang of Four (GoF).[1] The bridge uses

encapsulation, aggregation, and can use inheritance to
separate responsibilities into different classes.
When a class varies often, the features of object-oriented
programming become very useful because changes to a
program's code can be made easily with minimal prior
knowledge about the program. The bridge pattern is use-
ful when both the class and what it does vary often. The
class itself can be thought of as the abstraction and what
the class can do as the implementation. The bridge pattern
can also be thought of as two layers of abstraction.
When there is only one fixed implementation, this pattern Bridge in LePUS3 (legend)
is known as the Pimpl idiom in the C++ world.
The bridge pattern is often confused with the adapter
C#
pattern. In fact, the bridge pattern is often implemented
using the class adapter pattern, e.g. in the Java code
Bridge pattern compose objects in tree structure. It de-
below.
couples abstraction from implementation. Here abstrac-
Variant: The implementation can be decoupled even tion represents the client from which the objects will be
more by deferring the presence of the implementation to called. An example to implement in C# is given below
the point where the abstraction is utilized.
// Helps in providing truly decoupled architecture public
interface IBridge { void Function1(); void Function2(); }
3.3.1 Structure public class Bridge1 : IBridge { public void Function1() {
Console.WriteLine(“Bridge1.Function1”); } public void
Function2() { Console.WriteLine(“Bridge1.Function2”);
} } public class Bridge2 : IBridge { public void Func-
Abstraction tion1() { Console.WriteLine(“Bridge2.Function1”);
Implementor
} public void Function2() { Con-
- impl : Implementor sole.WriteLine(“Bridge2.Function2”); } } public
+ implementation()
+ function() interface IAbstractBridge { void CallMethod1();
void CallMethod2(); } public class AbstractBridge :
IAbstractBridge { public IBridge bridge; public Ab-
this.impl.implementation();
stractBridge(IBridge bridge) { this.bridge = bridge; }
public void CallMethod1() { this.bridge.Function1(); }
public void CallMethod2() { this.bridge.Function2(); } }
RefinedAbstraction ConcreteImplementor
As you can see, the Bridge classes are the Implementation
+ refinedFunction() + that
implementation()
uses the same interface-oriented architecture to cre-
ate objects. On the other hand, the abstraction takes an
object of the implementation phase and runs its method.
Thus, it makes completely decoupled from one another.
Abstraction (abstract class) defines the abstract inter-
face
Crystal
maintains the Implementor reference.
RefinedAbstraction (normal class) extends the inter- abstract class DrawingAPI abstract def draw_circle(x
face defined by Abstraction : Float64, y : Float64, radius : Float64) end class
DrawingAPI1 < DrawingAPI def draw_circle(x : Float,
Implementor (interface) defines the interface for im- y : Float, radius : Float) “API1.circle at #{x}:#{y}
plementation classes - radius: #{radius}" end end class DrawingAPI2
< DrawingAPI def draw_circle(x : Float64, y :
ConcreteImplementor (normal class) implements the Float64, radius : Float64) “API2.circle at #{x}:#{y}
Implementor interface - radius: #{radius}" end end abstract class Shape
protected getter drawing_api : DrawingAPI def ini-
tialize(@drawing_api) end abstract def draw abstract
3.3.2 Example def resize_by_percentage(percent : Float64) end class
CircleShape < Shape getter x : Float64 getter y : Float64
34 CHAPTER 3. STRUCTURAL PATTERNS

getter radius : Float64 def initialize(@x, @y, @radius, PHP

drawing_api : DrawingAPI) super(drawing_api) end def
draw @drawing_api.draw_circle(@x, @y, @radius) end interface DrawingAPI { function drawCircle($x, $y,
def resize_by_percentage(percent : Float64) @radius $radius); } class DrawingAPI1 implements DrawingAPI
*= (1 + percent/100) end end class BridgePattern { public function drawCircle($x, $y, $radius) { echo
def self.test shapes = [] of Shape shapes << Circle- “API1.circle at $x:$y radius $radius.\n"; } } class
Shape.new(1.0, 2.0, 3.0, DrawingAPI1.new) shapes << DrawingAPI2 implements DrawingAPI { public func-
CircleShape.new(5.0, 7.0, 11.0, DrawingAPI2.new) tion drawCircle($x, $y, $radius) { echo “API2.circle
shapes.each do |shape| shape.resize_by_percentage(2.5) at $x:$y radius $radius.\n"; } } abstract class Shape
puts shape.draw end end end BridgePattern.test { protected $drawingAPI; public abstract function
draw(); public abstract function resizeByPercent-
age($pct); protected function __construct(DrawingAPI
Output
$drawingAPI) { $this->drawingAPI = $drawingAPI;
API1.circle at 1.0:2.0 - radius: 3.075 API2.circle at } } class CircleShape extends Shape { private $x;
5.0:7.0 - radius: 11.275 private $y; private $radius; public function __con-
struct($x, $y, $radius, DrawingAPI $drawingAPI)
{ parent::__construct($drawingAPI); $this->x = $x;
$this->y = $y; $this->radius = $radius; } public function
draw() { $this->drawingAPI->drawCircle($this->x,
$this->y, $this->radius); } public function resizeByPer-
Java centage($pct) { $this->radius *= $pct; } } class Tester
{ public static function main() { $shapes = array(
The following Java (SE 6) program illustrates a 'shape'. new CircleShape(1, 3, 7, new DrawingAPI1()), new
CircleShape(5, 7, 11, new DrawingAPI2()), ); foreach
/** “Implementor” */ interface DrawingAPI { public ($shapes as $shape) { $shape->resizeByPercentage(2.5);
void drawCircle(final double x, final double y, final dou- $shape->draw(); } } } Tester::main();
ble radius); } /** “ConcreteImplementor” 1/2 */ class
DrawingAPI1 implements DrawingAPI { public void
drawCircle(final double x, final double y, final double Output:
radius) { System.out.printf(“API1.circle at %f:%f radius API1.circle at 1:3 radius 17.5 API2.circle at 5:7 radius
%f\n”, x, y, radius); } } /** “ConcreteImplementor” 2/2 27.5
*/ class DrawingAPI2 implements DrawingAPI { public
void drawCircle(final double x, final double y, final dou-
ble radius) { System.out.printf(“API2.circle at %f:%f Scala
radius %f\n”, x, y, radius); } } /** “Abstraction” */ ab-
stract class Shape { protected DrawingAPI drawingAPI; trait DrawingAPI { def drawCircle(x: Double, y:
protected Shape(final DrawingAPI drawingAPI){ Double, radius: Double) } class DrawingAPI1 extends
this.drawingAPI = drawingAPI; } public abstract void DrawingAPI { def drawCircle(x: Double, y: Double,
draw(); // low-level public abstract void resizeByPer- radius: Double) = println(s"API #1 $x $y $radius”)
centage(final double pct); // high-level } /** “Refined } class DrawingAPI2 extends DrawingAPI { def
Abstraction” */ class CircleShape extends Shape { pri- drawCircle(x: Double, y: Double, radius: Double)
vate double x, y, radius; public CircleShape(final double = println(s"API #2 $x $y $radius”) } abstract class
x, final double y, final double radius, final DrawingAPI Shape(drawingAPI: DrawingAPI) { def draw() def
drawingAPI) { super(drawingAPI); this.x = x; this.y = resizePercentage(pct: Double) } class CircleShape(x:
y; this.radius = radius; } // low-level i.e. Implementation Double, y: Double, var radius: Double, drawingAPI:
specific public void draw() { drawingAPI.drawCircle(x, DrawingAPI) extends Shape(drawingAPI: DrawingAPI)
y, radius); } // high-level i.e. Abstraction specific public { def draw() = drawingAPI.drawCircle(x, y, radius)
void resizeByPercentage(final double pct) { radius *= def resizePercentage(pct: Double) { radius *= pct } }
(1.0 + pct/100.0); } } /** “Client” */ class BridgePat- object BridgePattern { def main(args: Array[String]) {
tern { public static void main(final String[] args) { Seq ( new CircleShape(1, 3, 5, new DrawingAPI1), new
Shape[] shapes = new Shape[] { new CircleShape(1, CircleShape(4, 5, 6, new DrawingAPI2) ) foreach { x
2, 3, new DrawingAPI1()), new CircleShape(5, 7, 11, => x.resizePercentage(3) x.draw() } } }
new DrawingAPI2()) }; for (Shape shape : shapes) {
shape.resizeByPercentage(2.5); shape.draw(); } } }
3.3.3 See also
It will output:
• Adapter pattern
API1.circle at 1.000000:2.000000 radius 3.075000
API2.circle at 5.000000:7.000000 radius 11.275000 • Strategy pattern
3.4. COMPOSITE PATTERN 35

• Template method pattern good choice; it is less complex in this situation to treat
primitives and composites as homogeneous.

3.3.4 References
3.4.3 Structure
[1] Gamma, E, Helm, R, Johnson, R, Vlissides, J: Design Pat-
terns, page 151. Addison-Wesley, 1995

Component
0..*
3.3.5 External links + operation()
child

• Bridge in UML and in LePUS3 (a formal modelling

language)
• “C# Design Patterns: The Bridge Pattern”. Sample Leaf Composite

Chapter. From: James W. Cooper. C# Design Pat- + operation() + operation() 1

terns: A Tutorial. Addison-Wesley. ISBN 0-201- + add() parent

+ remove()
84453-2. + getChild()

3.4 Composite pattern Composite pattern in UML.

In software engineering, the composite pattern is a par-

titioning design pattern. The composite pattern describes Component
that a group of objects is to be treated in the same way as
a single instance of an object. The intent of a composite • is the abstraction for all components, including com-
is to “compose” objects into tree structures to represent posite ones
part-whole hierarchies. Implementing the composite pat-
tern lets clients treat individual objects and compositions • declares the interface for objects in the composition
uniformly.[1]
• (optional) defines an interface for accessing a com-
ponent’s parent in the recursive structure, and im-
3.4.1 Motivation plements it if that’s appropriate

When dealing with Tree-structured data, programmers Leaf

often have to discriminate between a leaf-node and a
branch. This makes code more complex, and therefore,
error prone. The solution is an interface that allows treat- • represents leaf objects in the composition
ing complex and primitive objects uniformly. In object-
• implements all Component methods
oriented programming, a composite is an object designed
as a composition of one-or-more similar objects, all ex-
hibiting similar functionality. This is known as a "has-a" Composite
relationship between objects.[2] The key concept is that
you can manipulate a single instance of the object just as • represents a composite Component (component
you would manipulate a group of them. The operations having children)
you can perform on all the composite objects often have a
least common denominator relationship. For example, if • implements methods to manipulate children
defining a system to portray grouped shapes on a screen,
it would be useful to define resizing a group of shapes to • implements all Component methods, generally by
have the same effect (in some sense) as resizing a single delegating them to its children
shape.

3.4.2 When to use 3.4.4 Variation

Composite should be used when clients ignore the dif-
ference between compositions of objects and individual
objects.[1] If programmers find that they are using multi-
ple objects in the same way, and often have nearly iden-
tical code to handle each of them, then composite is a
As it is described in Design Patterns, the pattern also in-
volves including the child-manipulation methods in the
main Component interface, not just the Composite sub-
class. More recent descriptions sometimes omit these
methods.[3]
36
Composite pattern in LePUS3.
3.4.5 Example
The following example, written in Java, implements a
graphic class, which can be either an ellipse or a compo-
sition of several graphics. Every graphic can be printed.
In Backus-Naur form,
Graphic ::= ellipse | GraphicList GraphicList ::= empty |
Graphic GraphicList
It could be extended to implement several other shapes
(rectangle, etc.) and methods (translate, etc.).
Java
/** “Component” */ interface Graphic { //Prints the
graphic. public void print(); } /** “Composite” */
import java.util.List; import java.util.ArrayList; class
CompositeGraphic implements Graphic { //Collection
of child graphics. private List<Graphic> childGraphics
= new ArrayList<Graphic>(); //Prints the graphic.
public void print() { for (Graphic graphic : childGraph-
ics) { graphic.print(); } } //Adds the graphic to the
composition. public void add(Graphic graphic) { child-
Graphics.add(graphic); } //Removes the graphic from
the composition. public void remove(Graphic graphic)
{ childGraphics.remove(graphic); } } /** “Leaf” */
class Ellipse implements Graphic { //Prints the graphic.
public void print() { System.out.println(“Ellipse”); }
} /** Client */ public class Program { public static
void main(String[] args) { //Initialize four ellipses
Ellipse ellipse1 = new Ellipse(); Ellipse ellipse2 =
new Ellipse(); Ellipse ellipse3 = new Ellipse(); Ellipse
ellipse4 = new Ellipse(); //Initialize three composite
graphics CompositeGraphic graphic = new Com-
positeGraphic(); CompositeGraphic graphic1 = new
CompositeGraphic(); CompositeGraphic graphic2
= new CompositeGraphic(); //Composes the graph-
ics graphic1.add(ellipse1); graphic1.add(ellipse2);
CHAPTER 3. STRUCTURAL PATTERNS
graphic1.add(ellipse3); graphic2.add(ellipse4);
graphic.add(graphic1); graphic.add(graphic2); //Prints
the complete graphic (four times the string “Ellipse”).
graphic.print(); } }
C#
The following example, written in C#.
namespace CompositePattern { using System; us-
ing System.Collections.Generic; using System.Linq;
//Client class Program { static void Main(string[]
args) { // initialize variables var compositeGraphic
= new CompositeGraphic(); var compositeGraphic1
= new CompositeGraphic(); var compositeGraphic2
= new CompositeGraphic(); //Add 1 Graphic to
compositeGraphic1 compositeGraphic1.Add(new
Ellipse()); //Add 2 Graphic to compositeGraphic2
compositeGraphic2.AddRange(new Ellipse(), new
Ellipse()); /*Add 1 Graphic, compositeGraphic1, and
compositeGraphic2 to compositeGraphic */ composite-
Graphic.AddRange(new Ellipse(), compositeGraphic1,
compositeGraphic2); /*Prints the complete graphic (four
times the string “Ellipse”).*/ compositeGraphic.Print();
Console.ReadLine(); } } //Component public interface
IGraphic { void Print(); } //Leaf public class Ellipse
: IGraphic { //Prints the graphic public void Print()
{ Console.WriteLine(“Ellipse”); } } //Composite
public class CompositeGraphic : IGraphic { //Col-
lection of Graphics. private readonly List<IGraphic>
graphics; //Constructor public CompositeGraphic()
{ //initialize generic Collection(Composition) graph-
ics = new List<IGraphic>(); } //Adds the graphic to
the composition public void Add(IGraphic graphic)
{ graphics.Add(graphic); } //Adds multiple graphics
to the composition public void AddRange(params
IGraphic[] graphic) { graphics.AddRange(graphic); }
//Removes the graphic from the composition public void
Delete(IGraphic graphic) { graphics.Remove(graphic);
} //Prints the graphic. public void Print() { foreach (var
childGraphic in graphics) { childGraphic.Print(); } } } }
//////Ad
Simple example /// Treats elements as composition
of one or more elements, so that components can be
separated /// between one another public interface
IComposite { void CompositeMethod(); } public class
LeafComposite :IComposite { public void Compos-
iteMethod() { //To Do something } } /// Elements
from IComposite can be separated from others public
class NormalComposite : IComposite { public void
CompositeMethod() { //To Do Something } public void
DoSomethingMore() { //Do Something more. } }
3.5. DECORATOR PATTERN 37

Crystal [2] Scott Walters (2004). Perl Design Patterns Book.

abstract class Graphic abstract def print end # Composite [3] Geary, David (13 Sep 2002). “A look at the Composite
design pattern”.
class CompositeGraphic < Graphic private getter graph-
ics def initialize @graphics = [] of Graphic end def print
@graphics.each do |graphic| graphic.print end end def
add(graphic : Graphic) @graphics.push(graphic) end def 3.5 Decorator pattern
remove(graphic : Graphic) @graphics.delete(graphic)
end end # Leaf class Ellipse < Graphic private getter Not to be confused with the concept of “decorators” in
name : String def initialize(@name) end def print puts Python.
“Ellipse #{name}" end end class Program def initialize
ellipse1 = Ellipse.new(“1”) ellipse2 = Ellipse.new(“2”)
In object-oriented programming, the decorator pattern
ellipse3 = Ellipse.new(“3”) ellipse4 = Ellipse.new(“4”)
(also known as Wrapper, an alternative naming shared
graphic = CompositeGraphic.new graphic1 = Compos-
with the Adapter pattern) is a design pattern that allows
iteGraphic.new graphic2 = CompositeGraphic.new #
behavior to be added to an individual object, either stat-
graphic 1 contains 3 ellipses graphic1.add(ellipse1)
ically or dynamically, without affecting the behavior of
graphic1.add(ellipse2) graphic1.add(ellipse3) #
other objects from the same class.[1] The decorator pat-
graphic 2 contains 1 ellipse graphic2.add(ellipse4)
tern is often useful for adhering to the Single Responsi-
# graphic contains both graphic 1 and graphic 2
bility Principle, as it allows functionality to be divided
graphic.add(graphic1) graphic.add(graphic2) # now
between classes with unique areas of concern.[2]
print the graphic graphic.print end end Program.new

3.5.1 Intent
3.4.6 See also
• Perl Design Patterns Book Component

• Mixin + operation()

• Law of Demeter

ConcreteComponent Decorator
3.4.7 External links - component
+ operation()
+ operation()
• Composite pattern description from the Portland
Pattern Repository
• Composite pattern in UML and in LePUS3, a for- ConcreteDecorator

mal modelling language + operation()

• Class::Delegation on CPAN
• “The End of Inheritance: Automatic Run-time In- Decorator UML class diagram
terface Building for Aggregated Objects” by Paul
Baranowski The decorator pattern can be used to extend (decorate)
the functionality of a certain object statically, or in some
• PerfectJPattern Open Source Project, Provides cases at run-time, independently of other instances of the
componentized implementation of the Composite same class, provided some groundwork is done at design
Pattern in Java time. This is achieved by designing a new Decorator class
• A persistent Java-based implementation that wraps the original class. This wrapping could be
achieved by the following sequence of steps:
• Composite Design Pattern
• Composite Design Pattern implementation example 1. Subclass the original Component class into a Deco-
rator class (see UML diagram);

3.4.8 References 2. In the Decorator class, add a Component pointer as

a field;
[1] Gamma, Erich; Richard Helm; Ralph Johnson; John M.
Vlissides (1995). Design Patterns: Elements of Reusable 3. In the Decorator class, pass a Component to the
Object-Oriented Software. Addison-Wesley. p. 395. Decorator constructor to initialize the Component
ISBN 0-201-63361-2. pointer;
38 CHAPTER 3. STRUCTURAL PATTERNS

4. In the Decorator class, forward all Component meth- no functionality for adding scrollbars. One could create
ods to the Component pointer; and a subclass ScrollingWindow that provides them, or create
a ScrollingWindowDecorator that adds this functionality
5. In the ConcreteDecorator class, override any Com- to existing Window objects. At this point, either solution
ponent method(s) whose behavior needs to be mod- would be fine.
ified.
Now, assume one also desires the ability to add borders to
This pattern is designed so that multiple decorators can windows. Again, the original Window class has no sup-
be stacked on top of each other, each time adding a new port. The ScrollingWindow subclass now poses a prob-
functionality to the overridden method(s). lem, because it has effectively created a new kind of win-
dow. If one wishes to add border support to many but not
Note that decorators and the original class object share all windows, one must create subclasses WindowWith-
a common set of features. In the previous diagram, the Border and ScrollingWindowWithBorder etc. This prob-
operation() method was available in both the decorated lem gets worse with every new feature or window subtype
and undecorated versions. to be added. For the decorator solution, we simply create
The decoration features (e.g., methods, properties, or a new BorderedWindowDecorator—at runtime, we can
other members) are usually defined by an interface, mixin decorate existing windows with the ScrollingWindowDec-
(a.k.a. trait) or class inheritance which is shared by the orator or the BorderedWindowDecorator or both, as we
decorators and the decorated object. In the previous ex- see fit. Notice that if the functionality needs to be added
ample the class Component is inherited by both the Con- to all Windows, you could modify the base class and that
creteComponent and the subclasses that descend from will do. On the other hand, sometimes (e.g., using exter-
Decorator. nal frameworks) it is not possible, legal, or convenient to
modify the base class.
The decorator pattern is an alternative to subclassing.
Subclassing adds behavior at compile time, and the Note, in the previous example, that the “SimpleWindow”
change affects all instances of the original class; deco- and “WindowDecorator” classes implement the “Win-
rating can provide new behavior at run-time for selective dow” interface, which defines the “draw()" method and
objects. the “getDescription()" method, that are required in this
scenario, in order to decorate a window control.
This difference becomes most important when there are
several independent ways of extending functionality. In
some object-oriented programming languages, classes 3.5.3 Usage
cannot be created at runtime, and it is typically not possi-
ble to predict, at design time, what combinations of exten- A decorator makes it possible to add or alter behavior of
sions will be needed. This would mean that a new class an interface at run-time. Alternatively, the adapter can be
would have to be made for every possible combination. used when the wrapper must respect a particular interface
By contrast, decorators are objects, created at runtime, and must support polymorphic behavior, and the Facade
and can be combined on a per-use basis. The I/O Streams when an easier or simpler interface to an underlying ob-
implementations of both Java and the .NET Framework ject is desired.[3]
incorporate the decorator pattern.

3.5.4 Examples
3.5.2 Motivation
C++

Two options are presented here, first a dynamic, runtime-

composable decorator (has issues with calling decorated
functions unless proxied explicitly) and a decorator that
uses mixin inheritance.

Dynamic Decorator struct Shape { virtual string

UML diagram for the window example
As an example, consider a window in a windowing sys-
tem. To allow scrolling of the window’s contents, one
may wish to add horizontal or vertical scrollbars to it,
as appropriate. Assume windows are represented by in-
stances of the Window class, and assume this class has
str() = 0; }; struct Circle : Shape { float radius = 10.0f;
void resize(float factor) { radius *= factor; } string
str() override { return string(“A circle of radius ") +
to_string(radius); } }; struct ColoredShape : Shape {
string color; Shape& shape; string str() override { return
shape.str() + string(" which is coloured ") + color; } };
// usage: Circle c; ColoredShape cc{"red”, c}; cout <<
cc.str() << endl; // cannot call this: cc.resize(1.2); // not
3.5. DECORATOR PATTERN 39

part of ColoredShape super.getDescription() + ", including horizontal scroll-

bars"; } }

Static Decorator (Mixin Inheritance) struct Cir- Here’s a test program that creates a Window instance
cle { float radius; void resize(float factor) { radius which is fully decorated (i.e., with vertical and horizontal
*= factor; } string str() { return string(“A circle of scrollbars), and prints its description:
radius”) + to_string(radius); } }; template <typename public class DecoratedWindowTest { public static
T> struct ColoredShape : T { string color; string str() void main(String[] args) { // Create a decorated Win-
{ return T::str() + " which is colored " + color; } }; dow with horizontal and vertical scrollbars Window
// usage: ColoredShape<Circle> red_circle{"red"}; decoratedWindow = new HorizontalScrollBarDec-
cout << red_circle.str() << endl; // and this is legal orator ( new VerticalScrollBarDecorator (new Sim-
red_circle.resize(1.2); pleWindow())); // Print the Window’s description
System.out.println(decoratedWindow.getDescription());
}}
Java
Below is the JUnit test class for the Test Driven Develop-
First example (window/scrolling scenario) The fol- ment
lowing Java example illustrates the use of decorators us- import static org.junit.Assert.assertEquals; import
ing the window/scrolling scenario. org.junit.Test; public class WindowDecoratorTest {
// The Window interface class public interface Window @Test public void testWindowDecoratorTest() { Win-
{ void draw(); // Draws the Window String getDe- dow decoratedWindow = new HorizontalScrollBarDec-
scription(); // Returns a description of the Window } orator(new VerticalScrollbarDecorator(new SimpleWin-
// Implementation of a simple Window without any dow())); // assert that the description indeed includes
scrollbars class SimpleWindow implements Window { horizontal + vertical scrollbars assertEquals(“simple
public void draw() { // Draw window } public String window, including vertical scrollbars, including horizon-
getDescription() { return “simple window"; } } tal scrollbars”, decoratedWindow.getDescription()) } }

The following classes contain the decorators for all Win- The output of this program is “simple window, including
dow classes, including the decorator classes themselves. vertical scrollbars, including horizontal scrollbars”. No-
tice how the getDescription method of the two decorators
// abstract decorator class - note that it implements
first retrieve the decorated Window’s description and dec-
Window abstract class WindowDecorator implements
orates it with a suffix.
Window { protected Window windowToBeDeco-
rated; // the Window being decorated public Win-
dowDecorator (Window windowToBeDecorated) {
this.windowToBeDecorated = windowToBeDecorated; Second example (coffee making scenario) The next
} public void draw() { windowToBeDecorated.draw(); Java example illustrates the use of decorators using cof-
//Delegation } public String getDescription() { return fee making scenario. In this example, the scenario only
windowToBeDecorated.getDescription(); //Delegation includes cost and ingredients.
} } // The first concrete decorator which adds vertical // The interface Coffee defines the functionality of
scrollbar functionality class VerticalScrollBarDecorator Coffee implemented by decorator public interface
extends WindowDecorator { public VerticalScroll- Coffee { public double getCost(); // Returns the cost of
BarDecorator (Window windowToBeDecorated) { the coffee public String getIngredients(); // Returns the
super(windowToBeDecorated); } @Override public ingredients of the coffee } // Extension of a simple coffee
void draw() { super.draw(); drawVerticalScrollBar(); without any extra ingredients public class SimpleCoffee
} private void drawVerticalScrollBar() { // Draw the implements Coffee { @Override public double getCost()
vertical scrollbar } @Override public String getDescrip- { return 1; } @Override public String getIngredients() {
tion() { return super.getDescription() + ", including return “Coffee"; } }
vertical scrollbars"; } } // The second concrete decorator
which adds horizontal scrollbar functionality class Hor-
izontalScrollBarDecorator extends WindowDecorator The following classes contain the decorators for all Coffee
{ public HorizontalScrollBarDecorator (Window win- classes, including the decorator classes themselves..
dowToBeDecorated) { super(windowToBeDecorated); // Abstract decorator class - note that it implements
} @Override public void draw() { super.draw(); Coffee interface public abstract class CoffeeDec-
drawHorizontalScrollBar(); } private void drawHor- orator implements Coffee { protected final Coffee
izontalScrollBar() { // Draw the horizontal scrollbar decoratedCoffee; public CoffeeDecorator(Coffee c) {
} @Override public String getDescription() { return this.decoratedCoffee = c; } public double getCost() { //
40 CHAPTER 3. STRUCTURAL PATTERNS

Implementing methods of the interface return decorat- = new ConcreteComponent(); $this->component =

edCoffee.getCost(); } public String getIngredients() { $this->wrapComponent($this->component); echo
return decoratedCoffee.getIngredients(); } } // Decora- $this->component->getData(); echo “Client:\t\t\t"; echo
tor WithMilk mixes milk into coffee. // Note it extends $this->component->getValue(); } private function wrap-
CoffeeDecorator. class WithMilk extends CoffeeDeco- Component(Component $component) { $component1
rator { public WithMilk(Coffee c) { super(c); } public = new ConcreteDecorator1($component); $component2
double getCost() { // Overriding methods defined in the = new ConcreteDecorator2($component1); return
abstract superclass return super.getCost() + 0.5; } public $component2; } } $client = new Client(); // Result:
String getIngredients() { return super.getIngredients() + #quanton81 //Concrete Component: 1000 //Concrete
", Milk"; } } // Decorator WithSprinkles mixes sprin- Decorator 1: 500 //Concrete Decorator 2: 500 //Client:
kles onto coffee. // Note it extends CoffeeDecorator. 2000
class WithSprinkles extends CoffeeDecorator { public
WithSprinkles(Coffee c) { super(c); } public double
getCost() { return super.getCost() + 0.2; } public String
getIngredients() { return super.getIngredients() + ", Python
Sprinkles"; } }
Python includes a more natural way of decorating a func-
tion by using an annotation on the function that is deco-
Here’s a test program that creates a Coffee instance which rated.
is fully decorated (with milk and sprinkles), and calculate
cost of coffee and prints its ingredients: def benchmark(func): """ Print the seconds that a
function takes to execute. """ from time import
public class Main { public static void printInfo(Coffee time def wrapper(*args, **kwargs): t0 = time()
c) { System.out.println(“Cost: " + c.getCost() + "; res = func(*args, **kwargs) print(“function @{0}
Ingredients: " + c.getIngredients()); } public static void took {1:0.3f} seconds”.format(func.__name__,
main(String[] args) { Coffee c = new SimpleCoffee(); time() - t0)) return res return wrapper @bench-
printInfo(c); c = new WithMilk(c); printInfo(c); c = new mark def wait_some_seconds(num_seconds =
WithSprinkles(c); printInfo(c); } } 1): from time import sleep sleep(num_seconds)
wait_some_seconds(1.11) # function
The output of this program is given below: @wait_some_seconds took 1.11 seconds
wait_some_seconds(5) # function @wait_some_seconds
Cost: 1.0; Ingredients: Coffee Cost: 1.5; Ingredients: took 5.000 seconds
Coffee, Milk Cost: 1.7; Ingredients: Coffee, Milk,
Sprinkles

PHP
abstract class Component { protected $data; protected
$value; abstract public function getData(); abstract
public function getValue(); } class ConcreteComponent
extends Component { public function __construct()
{ $this->value = 1000; $this->data = “Concrete
Component:\t{$this->value}\n"; } public function get-
Data() { return $this->data; } public function getValue()
{ return $this->value; } } abstract class Decorator ex-
tends Component { } class ConcreteDecorator1 extends
Decorator { public function __construct(Component
$data) { $this->value = 500; $this->data = $data; } pub-
lic function getData() { return $this->data->getData()
. “Concrete Decorator 1:\t{$this->value}\n"; } public
function getValue() { return $this->value + $this->data-
>getValue(); } } class ConcreteDecorator2 extends
Decorator { public function __construct(Component
$data) { $this->value = 500; $this->data = $data; } pub-
lic function getData() { return $this->data->getData()
. “Concrete Decorator 2:\t{$this->value}\n"; } public
function getValue() { return $this->value + $this->data-
>getValue(); } } class Client { private $component;
public function __construct() { $this->component
Crystal
abstract class Coffee abstract def cost abstract def
ingredients end # Extension of a simple coffee class
SimpleCoffee < Coffee def cost 1.0 end def ingredients
“Coffee” end end # Abstract decorator class CoffeeDec-
orator < Coffee protected getter decorated_coffee
: Coffee def initialize(@decorated_coffee) end def
cost decorated_coffee.cost end def ingredients dec-
orated_coffee.ingredients end end class WithMilk <
CoffeeDecorator def cost super + 0.5 end def ingre-
dients super + ", Milk” end end class WithSprinkles
< CoffeeDecorator def cost super + 0.2 end def in-
gredients super + ", Sprinkles” end end class Program
def print(coffee : Coffee) puts “Cost: #{coffee.cost};
Ingredients: #{coffee.ingredients}" end def initialize
coffee = SimpleCoffee.new print(coffee) coffee =
WithMilk.new(coffee) print(coffee) coffee = WithSprin-
kles.new(coffee) print(coffee) end end Program.new
Output:
Cost: 1.0; Ingredients: Coffee Cost: 1.5; Ingredients:
Coffee, Milk Cost: 1.7; Ingredients: Coffee, Milk,
Sprinkles
3.6. FACADE PATTERN 41

3.5.5 See also The Facade design pattern is often used when a system is
very complex or difficult to understand because the sys-
• Composite pattern tem has a large number of interdependent classes or its
source code is unavailable. This pattern hides the com-
• Adapter pattern plexities of the larger system and provides a simpler in-
• Abstract class terface to the client. It typically involves a single wrapper
class that contains a set of members required by client.
• Abstract factory These members access the system on behalf of the facade
client and hide the implementation details.
• Aspect-oriented programming

• Immutable object 3.6.1 Usage

A Facade is used when an easier or simpler interface to an
3.5.6 References
underlying object is desired.[1] Alternatively, an adapter
[1] Gamma, Erich; et al. (1995). Design Patterns. Read- can be used when the wrapper must respect a particu-
ing, MA: Addison-Wesley Publishing Co, Inc. pp. 175ff. lar interface and must support polymorphic behavior. A
ISBN 0-201-63361-2. decorator makes it possible to add or alter behavior of an
interface at run-time.
[2] “How to Implement a Decorator Pattern”. Archived from
the original on 2015-07-07. The facade pattern is typically used when

[3] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,

• a simple interface is required to access a complex
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
system,
“Head First Design Patterns” (paperback). 1. O'Reilly:
243, 252, 258, 260. ISBN 978-0-596-00712-6. Re- • a system is very complex or difficult to understand,
trieved 2012-07-02.
• an entry point is needed to each level of layered soft-
ware, or
3.5.7 External links
• the abstractions and implementations of a subsystem
• Decorator pattern description from the Portland Pat- are tightly coupled.
tern Repository

• Decorator pattern C++11 implementation example 3.6.2 Structure

3.6 Facade pattern

The facade pattern (also spelled façade) is a software
design pattern commonly used with object-oriented pro-
gramming. The name is by analogy to an architectural
façade.
A facade is an object that provides a simplified interface
to a larger body of code, such as a class library. A facade
can

• make a software library easier to use, understand

and test, since the facade has convenient methods
for common tasks,

• make the library more readable, for the same reason,

• reduce dependencies of outside code on the inner

workings of a library, since most code uses the fa-
cade, thus allowing more flexibility in developing the
system,

• wrap a poorly designed collection of APIs with a sin-

gle well-designed API.
42 CHAPTER 3. STRUCTURAL PATTERNS

Facade The facade class abstracts Packages 1, 2, and 3 body.SetBody(); accessories.SetAccessories(); Con-
from the rest of the application. sole.WriteLine("******** Car creation is completed.
**********"); } } // Facade pattern demo class Pro-
Clients The objects are using the Facade Pattern to ac- gram { static void Main(string[] args) { var facade =
cess resources from the Packages. new CarFacade(); facade.CreateCompleteCar(); Con-
sole.ReadKey(); } } }

3.6.3 Example

This is an abstract example of how a client (“you”) inter- Java

acts with a facade (the “computer”) to a complex system
(internal computer parts, like CPU and HardDrive).
/* Complex parts */ class CPU { public void freeze() { ...
} public void jump(long position) { ... } public void exe-
C# cute() { ... } } class HardDrive { public byte[] read(long
lba, int size) { ... } } class Memory { public void
Implementation namespace DesignPattern.Facade load(long position, byte[] data) { ... } } /* Facade */ class
{ class SubsystemA { public string OperationA1() { ComputerFacade { private CPU processor; private Mem-
return “Subsystem A, Method A1\n"; } public string ory ram; private HardDrive hd; public ComputerFacade()
OperationA2() { return “Subsystem A, Method A2\n"; { this.processor = new CPU(); this.ram = new Mem-
} } class SubsystemB { public string OperationB1() { ory(); this.hd = new HardDrive(); } public void start()
return “Subsystem B, Method B1\n"; } public string { processor.freeze(); ram.load(BOOT_ADDRESS,
OperationB2() { return “Subsystem B, Method B2\n"; hd.read(BOOT_SECTOR, SECTOR_SIZE)); proces-
} } class SubsystemC { public string OperationC1() { sor.jump(BOOT_ADDRESS); processor.execute(); } }
return “Subsystem C, Method C1\n"; } public string /* Client */ class You { public static void main(String[]
OperationC2() { return “Subsystem C, Method C2\n"; args) { ComputerFacade computer = new ComputerFa-
} } public class Facade { private readonly SubsystemA cade(); computer.start(); } }
a = new SubsystemA(); private readonly SubsystemB
b = new SubsystemB(); private readonly SubsystemC
c = new SubsystemC(); public void Operation1() {
Console.WriteLine(“Operation 1\n” + a.OperationA1() Ruby
+ b.OperationB1() + c.OperationC1()); } public void
Operation2() { Console.WriteLine(“Operation 2\n” + # Complex Parts class CPU def freeze; end def
a.OperationA2() + b.OperationB2() + c.OperationC2()); jump(position); end def execute; end end class Memory
}}} def load(position, data); end end class HardDrive def
read(lba, size); end end # Facade class Computer-
Facade def initialize @processor = CPU.new @ram
= Memory.new @hd = HardDrive.new end def start
Sample code namespace DesignPat- @processor.freeze @ram.load(BOOT_ADDRESS,
tern.Facade.Sample { // The 'Subsystem ClassA' @hd.read(BOOT_SECTOR, SECTOR_SIZE)) @pro-
class class CarModel { public void SetModel() { cessor.jump(BOOT_ADDRESS) @processor.execute
Console.WriteLine(" CarModel - SetModel”); } } end end # Client computer_facade = ComputerFa-
/// <summary> /// The 'Subsystem ClassB' class /// cade.new computer_facade.start
</summary> class CarEngine { public void SetEngine()
{ Console.WriteLine(" CarEngine - SetEngine”); }
} // The 'Subsystem ClassC' class class CarBody {
public void SetBody() { Console.WriteLine(" CarBody
3.6.4 References
- SetBody”); } } // The 'Subsystem ClassD' class class
CarAccessories { public void SetAccessories() { Con-
sole.WriteLine(" CarAccessories - SetAccessories”); [1] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,
Bert (2004). Hendrickson, Mike; Loukides, Mike, eds.
} } // The 'Facade' class public class CarFacade {
“Head First Design Patterns” (paperback). 1. O'Reilly:
private readonly CarAccessories accessories; private
243, 252, 258, 260. ISBN 978-0-596-00712-6. Re-
readonly CarBody body; private readonly CarEngine trieved 2012-07-02.
engine; private readonly CarModel model; public Car-
Facade() { accessories = new CarAccessories(); body
= new CarBody(); engine = new CarEngine(); model
= new CarModel(); } public void CreateComplete- 3.6.5 External links
Car() { Console.WriteLine("******** Creating a Car
**********"); model.SetModel(); engine.SetEngine(); • Description from the Portland Pattern Repository
3.7. FRONT CONTROLLER PATTERN 43

3.7 Front Controller pattern • ASP.NET MVC.

• Cairngorm framework in Adobe Flex.

The front controller software design pattern is listed in
several pattern catalogs and related to the design of Web • Drupal
applications. It is “a controller that handles all requests
for a Web site”,[1] which is a useful structure for Web • MVC frameworks written in PHP. For example, Yii,
application developers to achieve the flexibility and reuse CakePHP, Laravel, Symfony, CodeIgniter and Zend
without code redundancy. Framework

• Spring Framework[2]
3.7.1 Instruction • Yesod Web application framework written in
Haskell.

Handler «abstract»
Command 3.7.3 Implementation
doGet()
doPost() process()
To better understand front controller pattern, there is an
example to implement front controller in Java.[3] It can be
defined in 3 components:

1. XML Mapping: files that map requests to the class

«concrete» «concrete»
Command 1 Command 2
that will handle the request processing.
process() process() 2. Request Processor: used for dealing with the request
processing (and modifying or retrieving the appro-
priate model).
A typical front controller structure.
3. Flow Manager: first get the request and the output
of the processing, then determine what will show on
Front controllers are often used in Web applications to the next page.
implement workflows. While not strictly required, it is
much easier to control navigation across a set of related
pages (for instance, multiple pages used in an online pur- Participants and responsibilities
chase) from a front controller than it is to make the indi-
vidual pages responsible for navigation. Demo implementation in Java
The front controller may be implemented as a Jav2a ob-
Here is part of a demo code to implement front
ject, or as a script in a script language like PHP, Python
controller.[4]
or Ruby that is called on every request of a Web session.
This script, for example an index.php, would handle all 1 private void doProcess(HttpServletRequest request, 2
tasks that are common to the application or the frame- HttpServletResponse response) 3 throws IOException,
work, such as session handling, caching, and input filter- ServletException { 4 ... 5 try { 6 getRequestPro-
ing. Based on the specific request, it would then instanti- cessor().processRequest(request); 7 8 getScreen-
ate further objects and call methods to handle the partic- FlowManager().forwardToNextScreen(request, re-
ular task(s) required. sponse); 9 } catch (Throwable ex) { 10 String class-
Name = ex.getClass().getName(); 11 nextScreen =
The alternative to a front controller would be individual
getScreenFlowManager().getExceptionScreen(ex);
scripts like login.php and order.php that would each then
12 // put the exception in the request 13 re-
satisfy the type of request. Each script would have to
quest.setAttribute(“javax.servlet.jsp.jspException”,
duplicate code or objects that are common to all tasks.
ex); 14 if (nextScreen == null) { 15 // send to general
However, each script might also have more flexibility to
error screen 16 ex.printStackTrace(); 17 throw new
implement the particular task required.
ServletException(“MainServlet: unknown exception: "
+ 18 className); 19 } 20 }
3.7.2 Examples

Several Web-tier application frameworks implement the 3.7.4 Benefits and liabilities
front controller pattern, among them:
There are three benefits for using front controller
• Apache Struts. pattern.[5]
44 CHAPTER 3. STRUCTURAL PATTERNS

• Centralized control. Front controller handles all 3.7.8 References

the requests to the Web application. This implemen-
tation of centralized control that avoids using multi- [1] Fowler, Martin. “Front Controller”. martinfowler.
ple controllers is desirable for enforcing application- [2] “Web MVC framework”.
wide policies such as users tracking and security.
[3] “Front Controller Pattern”.
• Thread-safety. A new command object arises
[4] “Demo code in Java”. Archived from the original on
when receiving a new request and the command ob- 2012-04-19.
jects are not meant to be thread safe. Thus, it will
be safe in the command classes. Though safety is [5] “Benefits for using front controller”.
not guaranteed when threading issues are gathered,
codes that act with command is still thread safe.
3.7.9 Notes
• Configurability. Since only one front controller
• Alur, Deepak; John Crup; Dan Malks (2003). Core
is needed in Web application, the configuration of
J2EE Patterns, Best Practices and Design Strategies,
Web applications implementation is largely simpli-
2nd Ed. Sun Microsystems Press. pp. 650pp. ISBN
fied. The handler accomplishes the rest of dispatch-
0-13-142246-4.
ing so that it is not required to change anything be-
fore adding new commands with dynamic ones. • Fowler, Martin. Patterns of Enterprise Application
Architecture. pp. 560pp. ISBN 978-0-321-12742-
In terms of liability, front controllers that determine the 6.
following activities by searching the database or XML • Fowler, Martin. “Front Controller”. Retrieved
documents, performance might be decreased. And im- February 2, 2008.
plementation of front controller to existed systems al-
ways involving replacing the current ones, which makes
it harder for beginners to start with. 3.7.10 External links
• Bear Bibeault’s Front Man™, A lightweight Java
3.7.5 Relationship with MVC pattern implementation.

1. In order to improve system reliability and maintain-

ability, duplicated codes should be avoided and cen- 3.8 Flyweight pattern
tralized when they are of the same common logic
through the whole system. In computer programming, flyweight is a software design
pattern. A flyweight is an object that minimizes memory
2. The data for the application is better to be handled in usage by sharing as much data as possible with other sim-
one location, thus there will be no need to duplicate ilar objects; it is a way to use objects in large numbers
database retrieval code. when a simple repeated representation would use an un-
acceptable amount of memory. Often some parts of the
3. Different roles in the MVC pattern should be sep- object state can be shared, and it is common practice to
arated to increase testability, which is also true for hold them in external data structures and pass them to the
controller part in the MVC pattern. flyweight objects temporarily when they are used.
A classic example usage of the flyweight pattern is the
data structures for graphical representation of characters
3.7.6 Comparison in a word processor. It might be desirable to have, for
each character in a document, a glyph object contain-
Page controller is an alternative to front controller in ing its font outline, font metrics, and other formatting
MVC model. data, but this would amount to hundreds or thousands
of bytes for each character. Instead, for every charac-
ter there might be a reference to a flyweight glyph object
shared by every instance of the same character in the doc-
3.7.7 See also ument; only the position of each character (in the docu-
ment and/or the page) would need to be stored internally.
• Design pattern (computer science).
Another example is string interning.
• Mediator pattern *Note: the front controller pattern In other contexts the idea of sharing identical data struc-
is a specialized kind of mediator pattern. tures is called hash consing.
3.8. FLYWEIGHT PATTERN
3.8.1 History
According to the textbook Design Patterns: Elements of
Reusable Object-Oriented Software,[1] the flyweight pat-
tern was first coined and extensively explored by Paul
Calder and Mark Linton in 1990 to efficiently handle
glyph information in a WYSIWYG document editor,[2]
although similar techniques were already used in other
systems, e.g., an application framework by Weinand et
al. (1988).[3]
3.8.2 Immutability and equality
To enable safe sharing, between clients and threads, Fly-
weight objects must be immutable. Flyweight objects are
by definition value objects. The identity of the object in-
stance is of no consequence therefore two Flyweight in-
stances of the same value are considered equal.
Example in C# (note Equals and GetHashCode overrides
as well as == and != operator overloads):
public class CoffeeFlavour { private readonly string
_flavour; public CoffeeFlavour(string flavour) { _flavour
= flavour; } public string Flavour { get { return
_flavour; } } public override bool Equals(object obj)
{ if (ReferenceEquals(null, obj)) return false; return
obj is CoffeeFlavour && Equals((CoffeeFlavour)obj);
} public bool Equals(CoffeeFlavour other) { return
string.Equals(_flavour, other._flavour); } public over-
ride int GetHashCode() { return (_flavour != null
? _flavour.GetHashCode() : 0); } public static bool
operator ==(CoffeeFlavour a, CoffeeFlavour b) {
return Equals(a, b); } public static bool operator !=(Cof-
feeFlavour a, CoffeeFlavour b) { return !Equals(a, b); } }
3.8.3 Concurrency
Special consideration must be made in scenarios where
Flyweight objects are created on multiple threads. If the
list of values is finite and known in advance the Flyweights
can be instantiated ahead of time and retrieved from a
container on multiple threads with no contention. If Fly-
weights are instantiated on multiple threads there are two
options:
1. Make Flyweight instantiation single threaded thus
introducing contention and ensuring one instance
per value.
2. Allow concurrent threads to create multiple Fly- 3.8.5 Example in Java
weight instances thus eliminating contention and al-
lowing multiple instances per value. This option is import java.util.List;
only viable if the equality criterion is met. import
45
3.8.4 Example in C#
using System.Collections.Concurrent; using Sys-
tem.Collections.Generic; using System.Threading;
public interface ICoffeeFlavourFactory { CoffeeFlavour
GetFlavour(string flavour); } public class Reduced-
MemoryFootprint : ICoffeeFlavourFactory { private
readonly object _cacheLock = new object(); pri-
vate readonly IDictionary<string, CoffeeFlavour>
_cache = new Dictionary<string, CoffeeFlavour>();
public CoffeeFlavour GetFlavour(string flavour) { if
(_cache.ContainsKey(flavour)) return _cache[flavour];
var coffeeFlavour = new CoffeeFlavour(flavour);
ThreadPool.QueueUserWorkItem(AddFlavourToCache,
coffeeFlavour); return coffeeFlavour; } pri-
vate void AddFlavourToCache(object state) {
var coffeeFlavour = (CoffeeFlavour)state; if
(!_cache.ContainsKey(coffeeFlavour.Flavour))
{ lock (_cacheLock) { if
(!_cache.ContainsKey(coffeeFlavour.Flavour))
_cache.Add(coffeeFlavour.Flavour, coffeeFlavour);
} } } } public class MinimumMemoryFootprint :
ICoffeeFlavourFactory { private readonly Concur-
rentDictionary<string, CoffeeFlavour> _cache =
new ConcurrentDictionary<string, CoffeeFlavour>();
public CoffeeFlavour GetFlavour(string flavour) {
return _cache.GetOrAdd(flavour, flv => new Cof-
feeFlavour(flv)); } }
Simple implementation
Flyweight allows you to share bulky data that are common
to each object. In other words, if you think that same data
is repeating for every object, you can use this pattern to
point to the single object and hence can easily save space.
Here the FlyweightPointer creates a static member Com-
pany, which is used for every object of MyObject.
// Defines Flyweight object that repeats itself. public
class FlyWeight { public string CompanyName { get;
set; } public string CompanyLocation { get; set; }
public string CompanyWebSite { get; set; } //Bulky
Data public byte[] CompanyLogo { get; set; } } public
static class FlyWeightPointer { public static readonly
FlyWeight Company = new FlyWeight { CompanyName
= “Abc”, CompanyLocation = “XYZ”, CompanyWeb-
Site = "www.abc.com" // Load CompanyLogo here };
} public class MyObject { public string Name { get;
set; } public string Company { get { return FlyWeight-
Pointer.Company.CompanyName; } } }
import java.util.Map;
java.util.Vector; import
46
java.util.concurrent.ConcurrentHashMap; // Instances of
CoffeeFlavour will be the Flyweights class CoffeeFlavour
{ private final String name; CoffeeFlavour(final String
newFlavor) { this.name = newFlavor; } @Override public
String toString() { return name; } } // Menu acts as a fac-
tory and cache for CoffeeFlavour flyweight objects class
Menu { private Map<String, CoffeeFlavour> flavours
= new ConcurrentHashMap<String, CoffeeFlavour>();
synchronized CoffeeFlavour lookup(final String fla-
vorName) { if (!flavours.containsKey(flavorName))
flavours.put(flavorName, new Cof-
feeFlavour(flavorName)); return
flavours.get(flavorName); } synchronized int total-
CoffeeFlavoursMade() { return flavours.size(); } } //
Order is the context of the CoffeeFlavour flyweight.
class Order { private final int tableNumber; private
final CoffeeFlavour flavour; Order(final int tableNum-
ber, final CoffeeFlavour flavor) { this.tableNumber =
tableNumber; this.flavour = flavor; } void serve() {
System.out.println(“Serving " + flavour + " to table " +
tableNumber); } } public class CoffeeShop { private final
List<Order> orders = new Vector<Order>(); private
final Menu menu = new Menu(); void takeOrder(final
String flavourName, final int table) { CoffeeFlavour
flavour = menu.lookup(flavourName); Order order =
new Order(table, flavour); orders.add(order); } void
service() { for (Order order : orders) order.serve(); }
String report() { return "\ntotal CoffeeFlavour objects
made: " + menu.totalCoffeeFlavoursMade(); } public
static void main(final String[] args) { CoffeeShop shop =
new CoffeeShop(); shop.takeOrder(“Cappuccino”,
2); shop.takeOrder(“Frappe”, 1);
shop.takeOrder(“Espresso”, 1);
shop.takeOrder(“Frappe”, 897);
shop.takeOrder(“Cappuccino”,
97); shop.takeOrder(“Frappe”, 3);
shop.takeOrder(“Espresso”, 3);
shop.takeOrder(“Cappuccino”, 3);
shop.takeOrder(“Espresso”, 96);
shop.takeOrder(“Frappe”, 552);
shop.takeOrder(“Cappuccino”, 121);
shop.takeOrder(“Espresso”, 121); shop.service();
System.out.println(shop.report()); } }
3.8.6 Example in Scala
/* https://gist.github.com/pkinsky/
111aee2f129c03ff1d0d run as a script using
`scala flyweight.scala` expected output: Serving
CoffeeFlavour(Espresso) to table 121 Serving
CoffeeFlavour(Cappuccino) to table 121 Serv-
ing CoffeeFlavour(Frappe) to table 552 Serv-
ing CoffeeFlavour(Espresso) to table 96 Serv-
ing CoffeeFlavour(Cappuccino) to table 3 Serv-
ing CoffeeFlavour(Espresso) to table 3 Serv-
ing CoffeeFlavour(Frappe) to table 3 Serving
CHAPTER 3. STRUCTURAL PATTERNS
CoffeeFlavour(Cappuccino) to table 97 Serv-
ing CoffeeFlavour(Frappe) to table 897 Serv-
ing CoffeeFlavour(Espresso) to table 1 Serv-
ing CoffeeFlavour(Frappe) to table 1 Serv-
ing CoffeeFlavour(Cappuccino) to table 2 total
CoffeeFlavour objects made: 3 */ class Cof-
feeFlavour(val name: String){ override def toString
= s"CoffeeFlavour($name)" } object CoffeeFlavour {
import scala.collection.mutable.Map private val cache
= Map.empty[String, CoffeeFlavour] def apply(name:
String): CoffeeFlavour = cache.getOrElseUpdate(name,
new CoffeeFlavour(name)) def totalCoffeeFlavours-
Made = cache.size } case class Order(tableNumber:
Int, flavour: CoffeeFlavour){ def serve: Unit =
println(s"Serving $flavour to table $tableNumber”) }
object CoffeeShop { var orders = List.empty[Order]
def takeOrder(flavourName: String, table: Int) {
val flavour = CoffeeFlavour(flavourName) val or-
der = Order(table, flavour) orders = order :: or-
ders } def service: Unit = orders.foreach(_.serve)
def report = s"total CoffeeFlavour objects made:
${CoffeeFlavour.totalCoffeeFlavoursMade}"
} CoffeeShop.takeOrder(“Cappuccino”, 2)
CoffeeShop.takeOrder(“Frappe”, 1) Cof-
feeShop.takeOrder(“Espresso”, 1) Cof-
feeShop.takeOrder(“Frappe”, 897) Cof-
feeShop.takeOrder(“Cappuccino”, 97) Cof-
feeShop.takeOrder(“Frappe”, 3) Cof-
feeShop.takeOrder(“Espresso”, 3) Cof-
feeShop.takeOrder(“Cappuccino”, 3) Cof-
feeShop.takeOrder(“Espresso”, 96) Cof-
feeShop.takeOrder(“Frappe”, 552) Cof-
feeShop.takeOrder(“Cappuccino”, 121) Cof-
feeShop.takeOrder(“Espresso”, 121) CoffeeShop.service
println(CoffeeShop.report)
3.8.7 Example in Ruby
# Flyweight Object class Lamp attr_reader :color
#attr_reader makes color attribute available outside
#of the class by calling .color on a Lamp instance def
initialize(color) @color = color end end class Tree-
Branch def initialize(branch_number) @branch_number
= branch_number end def hang(lamp) puts “Hang
#{lamp.color} lamp on branch #{@branch_number}"
end end # Flyweight Factory class LampFactory def
initialize @lamps = {} end def find_lamp(color) if
@lamps.has_key?(color) # if the lamp already exists,
reference it instead of creating a new one lamp
= @lamps[color] else lamp = Lamp.new(color)
@lamps[color] = lamp end lamp end def to-
tal_number_of_lamps_made @lamps.size end end
class ChristmasTree def initialize @lamp_factory =
LampFactory.new @lamps_hung = 0 dress_up_the_tree
end def hang_lamp(color, branch_number) Tree-
Branch.new(branch_number).hang(@lamp_factory.find_lamp(color))
3.8. FLYWEIGHT PATTERN 47

@lamps_hung += 1 end def dress_up_the_tree Brand shop1.sell_cheese('blue', 3) # Both can sell

hang_lamp('red', 1) hang_lamp('blue', 1) shop2.sell_cheese('blue', 8) # But the units sold are
hang_lamp('yellow', 1) hang_lamp('red', 2) stored per-instance assert shop1.total_units_sold()
hang_lamp('blue', 2) hang_lamp('yellow', 2) == 3 assert shop1.total_income() == 3.75 *
hang_lamp('red', 3) hang_lamp('blue', 3) 3 assert shop2.total_units_sold() == 8 assert
hang_lamp('yellow', 3) hang_lamp('red', 4) shop2.total_income() == 3.75 * 8
hang_lamp('blue', 4) hang_lamp('yellow', 4)
hang_lamp('red', 5) hang_lamp('blue', 5)
hang_lamp('yellow', 5) hang_lamp('red', 6)
hang_lamp('blue', 6) hang_lamp('yellow', 3.8.9 Example in Swift
6) hang_lamp('red', 7) hang_lamp('blue',
7) hang_lamp('yellow', 7) puts “Made import Foundation // Instances of CoffeeFlavour will
#{@lamp_factory.total_number_of_lamps_made} be the Flyweights struct CoffeeFlavor : CustomString-
total lamps” puts “Hung #{@lamps_hung} total lamps” Convertible { var flavor: String var description: String
end end { return flavor } } // Menu acts as a factory and cache
for CoffeeFlavour flyweight objects struct Menu {
private var flavors = [String: CoffeeFlavor]() mutating
func lookup(flavor: String) -> CoffeeFlavor { if let f
3.8.8 Example in Python = flavors[flavor] { return f } else { let cFlavor = Cof-
feeFlavor(flavor: flavor) flavors[flavor] = cFlavor return
Attributes can be defined at the class-level instead of only cFlavor } } } struct CoffeeShop { private var orders
for instances in Python because classes are first-class ob- = [Int: CoffeeFlavor]() private var menu = Menu()
jects in the language—meaning there are no restrictions mutating func takeOrder(flavor flavor: String, table: Int)
on their use as they are the same as any other object. { orders[table] = menu.lookup(flavor) } func serve() {
New-style class instances store instance data in a special for (table, flavor) in orders { print(“Serving \(flavor) to
attribute dictionary instance.__dict__. By default, ac- table \(table)") } } } let coffeeShop = CoffeeShop()
cessed attributes are first looked-up in this __dict__, and coffeeShop.takeOrder(flavor: “Cappuccino”, table:
then fallback to the instance’s class attributes next. [4] In 1) coffeeShop.takeOrder(flavor: “Frappe”, table: 3);
this way, a class can effectively be a kind of Flyweight coffeeShop.takeOrder(flavor: “Espresso”, table: 2);
container for its instances. coffeeShop.takeOrder(flavor: “Frappe”, table: 15);
Although Python classes are mutable by default, im- coffeeShop.takeOrder(flavor: “Cappuccino”, table:
mutability can be emulated by overriding the class’s __se- 10); coffeeShop.takeOrder(flavor: “Frappe”, table: 8);
tattr__ method so that it disallows changes to any Fly- coffeeShop.takeOrder(flavor: “Espresso”, table: 7);
weight attributes. coffeeShop.takeOrder(flavor: “Cappuccino”, table: 4);
coffeeShop.takeOrder(flavor: “Espresso”, table: 9);
# Instances of CheeseBrand will be the Flyweights class coffeeShop.takeOrder(flavor: “Frappe”, table: 12);
CheeseBrand(object): def __init__(self, brand, cost): coffeeShop.takeOrder(flavor: “Cappuccino”, table: 13);
self.brand = brand self.cost = cost self._immutable coffeeShop.takeOrder(flavor: “Espresso”, table: 5);
= True # Disables future attributions def __se- coffeeShop.serve()
tattr__(self, name, value): if getattr(self, '_im-
mutable', False): # Allow initial attribution raise
RuntimeError('This object is immutable') else: su-
per(CheeseBrand, self).__setattr__(name, value) 3.8.10 Example in Crystal
class CheeseShop(object): menu = {} # Shared con-
tainer to access the Flyweights def __init__(self): # Instances of CoffeeFlavor will be the Flyweights class
self.orders = {} # per-instance container with pri- CoffeeFlavor def initialize(new_flavor : String) @name
vate attributes def stock_cheese(self, brand, cost): = new_flavor end def to_s(io) io << @name end end
cheese = CheeseBrand(brand, cost) self.menu[brand] # Menu acts as a factory and cache for CoffeeFlavor
= cheese # Shared Flyweight def sell_cheese(self, flyweight objects class Menu def initialize @flavors = {}
brand, units): self.orders.setdefault(brand, 0) of String => CoffeeFlavor end def lookup(flavor_name
self.orders[brand] += units # Instance attribute def : String) @flavors[flavor_name] ||= CoffeeFla-
total_units_sold(self): return sum(self.orders.values()) vor.new(flavor_name) end def total_flavors_made
def total_income(self): income = 0 for brand, units in @flavors.size end end # Order is the context of the
self.orders.items(): income += self.menu[brand].cost CoffeeFlavor flyweight. class Order private getter
* units return income shop1 = CheeseShop() table_number : Int32, flavor : CoffeeFlavor def ini-
shop2 = CheeseShop() shop1.stock_cheese('white', tialize(@table_number, @flavor) end def serve puts
1.25) shop1.stock_cheese('blue', 3.75) # Now ev- “Serving #{flavor} to table #{table_number}" end end
ery CheeseShop have 'white' and 'blue' on the class CoffeeShop private getter orders private getter
inventory # The SAME 'white' and 'blue' Cheese- menu def initialize @orders = [] of Order @menu =
48 CHAPTER 3. STRUCTURAL PATTERNS

Menu.new end def take_order(flavor_name : String, 3.9 Proxy pattern

table : Int32) flavor = menu.lookup(flavor_name)
order = Order.new(table, flavor) @orders << order
end def service orders.each do |order| order.serve Client <<interface>>
end end def report “Total CoffeeFlavor made: Subject

#{menu.total_flavors_made}" end end # Program shop DoAction()

= CoffeeShop.new shop.take_order(“Cappuchino”,
2) shop.take_order(“Frappe”, 1)
shop.take_order(“Espresso”, 1)
shop.take_order(“Frappe”, 897)
delegate
Proxy RealSubject
shop.take_order(“Cappuccino”,
97) shop.take_order(“Frappe”, 3)
DoAction() DoAction()
shop.take_order(“Espresso”, 3)
shop.take_order(“Cappuccino”, 3)
shop.take_order(“Espresso”, 96) Proxy in UML
shop.take_order(“Frappe”, 552)
shop.take_order(“Cappuccino”, 121)
shop.take_order(“Espresso”, 121) shop.service puts
shop.report

Output
Serving Cappuchino to table 2 Serving Frappe to table 1
Serving Espresso to table 1 Serving Frappe to table 897
Serving Cappuccino to table 97 Serving Frappe to table 3
Serving Espresso to table 3 Serving Cappuccino to table
3 Serving Espresso to table 96 Serving Frappe to table Proxy in LePUS3 (legend)
552 Serving Cappuccino to table 121 Serving Espresso
In computer programming, the proxy pattern is a
to table 121 Total CoffeeFlavor made: 4
software design pattern.
A proxy, in its most general form, is a class functioning
3.8.11 See also as an interface to something else. The proxy could inter-
face to anything: a network connection, a large object in
• Copy-on-write memory, a file, or some other resource that is expensive
• Memoization or impossible to duplicate. In short, a proxy is a wrapper
or agent object that is being called by the client to ac-
• Multiton cess the real serving object behind the scenes. Use of the
proxy can simply be forwarding to the real object, or can
provide additional logic. In the proxy extra functionality
3.8.12 References can be provided, for example caching when operations on
[1] Gamma, Erich; Richard Helm; Ralph Johnson; John Vlis-
the real object are resource intensive, or checking precon-
sides (1995). Design Patterns: Elements of Reusable ditions before operations on the real object are invoked.
Object-Oriented Software. Addison-Wesley. pp. 205– For the client, usage of a proxy object is similar to using
206. ISBN 0-201-63361-2. the real object, because both implement the same inter-
face.
[2] Calder, Paul R.; Linton, Mark A. (October 1990). Glyphs:
Flyweight Objects for User Interfaces. The 3rd Annual
ACM SIGGRAPH Symposium on User Interface Soft- 3.9.1 Possible Usage Scenarios
ware and Technology. Snowbird, Utah, United States. pp.
92–101. doi:10.1145/97924.97935. ISBN 0-89791-410-
Remote Proxy
4.

[3] Weinand, Andre; Gamma, Erich; Marty, Rudolf
(1988). ET++—an object oriented application frame-
work in C++. OOPSLA (Object-Oriented Program-
ming Systems, Languages and Applications). San
Diego, California, United States. pp. 46–57.
doi:10.1145/62083.62089. ISBN 0-89791-284-5.
[4] “Date Model §". The (online) Python Language Reference.
Python Software Foundation. Retrieved 7 March 2017.
In distributed object communication, a local object rep-
resents a remote object (one that belongs to a different
address space). The local object is a proxy for the remote
object, and method invocation on the local object results
in remote method invocation on the remote object. An
example would be an ATM implementation, where the
ATM might hold proxy objects for bank information that
exists in the remote server.
3.9. PROXY PATTERN 49

Virtual Proxy _driver_age; public: ProxyCar (const int driver_age)

In place of a complex or heavy object, a skeleton repre-
sentation may be advantageous in some cases. When an
underlying image is huge in size, it may be represented
using a virtual proxy object, loading the real object on
demand.
: _driver_age(driver_age) {} void DriveCar() { if
(_driver_age > 16) realCar->DriveCar(); else std::cout
<< “Sorry, the driver is too young to drive."; } }; // How
to use above Proxy class? void main() { ICar* car = new
ProxyCar(16); car->DriveCar(); delete car; car = new
ProxyCar(25); car->DriveCar(); delete car; }

Protection Proxy
Crystal
A protection proxy might be used to control access to a
resource based on access rights. abstract class AbstractCar abstract def drive end class
Car < AbstractCar def drive puts “Car has been
driven!" end end class Driver getter age : Int32 def
3.9.2 Example initialize(@age) end end class ProxyCar < AbstractCar
private getter driver : Driver private getter real_car
C#
: AbstractCar def initialize(@driver) @real_car =
Car.new end def drive if driver.age <= 16 puts “Sorry,
interface ICar { void DriveCar(); } // Real Object
the driver is too young to drive.” else @real_car.drive
public class Car : ICar { public void DriveCar() {
end end end # Program driver = Driver.new(16) car =
Console.WriteLine(“Car has been driven!"); } } //Proxy
ProxyCar.new(driver) car.drive driver = Driver.new(25)
Object public class ProxyCar : ICar { private Driver
car = ProxyCar.new(driver) car.drive
driver; private ICar realCar; public ProxyCar(Driver
driver) { this.driver = driver; this.realCar = new Car();
} public void DriveCar() { if (driver.Age <= 16) Output
Console.WriteLine(“Sorry, the driver is too young to Sorry, the driver is too young to drive. Car has been
drive.”); else this.realCar.DriveCar(); } } public class driven!
Driver { private int Age { get; set; } public Driver(int
age) { this.Age = age; } } // How to use above Proxy
class? private void btnProxy_Click(object sender, Even- Delphi / Object Pascal
tArgs e) { ICar car = new ProxyCar(new Driver(16));
car.DriveCar(); car = new ProxyCar(new Driver(25)); // Proxy Design pattern unit DesignPattern.Proxy;
car.DriveCar(); } interface type // Car Interface ICar = interface pro-
cedure DriveCar; end; // TCar class, implementing
Output ICar TCar = Class(TInterfacedObject, ICar) class
function New: ICar; procedure DriveCar; End; // Driver
Sorry, the driver is too young to drive. Car has been Interface IDriver = interface function Age: Integer;
driven! end; // TDriver Class, implementing IDriver TDriver =
Notes: Class(TInterfacedObject, IDriver) private FAge: Inte-
ger; public constructor Create(Age: Integer); Overload;
• A proxy may hide information about the real object class function New(Age: Integer): IDriver; function
to the client. Age: Integer; End; // Proxy Object TProxyCar =
Class(TInterfacedObject, ICar) private FDriver: IDriver;
• A proxy may perform optimization like on demand FRealCar: ICar; public constructor Create(Driver:
loading. IDriver); Overload; class function New(Driver: IDriver):
ICar; procedure DriveCar; End; implementation { TCar
• A proxy may do additional house-keeping job like Implementation } class function TCar.New: ICar; begin
audit tasks. Result := Create; end; procedure TCar.DriveCar; begin
• Proxy design pattern is also known as surrogate de- WriteLn('Car has been driven!'); end; { TDriver Imple-
sign pattern. mentation } constructor TDriver.Create(Age: Integer);
begin inherited Create; FAge := Age; end; class function
TDriver.New(Age: Integer): IDriver; begin Result :=
C++ Create(Age); end; function TDriver.Age: Integer; begin
Result := FAge; end; { TProxyCar Implementation }
class ICar { public: virtual void DriveCar() = 0; }; constructor TProxyCar.Create(Driver: IDriver); begin
class Car : public ICar { void DriveCar() override { inherited Create; Self.FDriver := Driver; Self.FRealCar
std::cout << “Car has been driven!"; } }; class ProxyCar := TCar.Create AS ICar; end; class function TProx-
: public ICar { private: ICar* realCar = new Car(); int yCar.New(Driver: IDriver): ICar; begin Result :=
50 CHAPTER 3. STRUCTURAL PATTERNS

Create(Driver); end; procedure TProxyCar.DriveCar; age1.displayImage(); // loading unnecessary im-

begin if (FDriver.Age <= 16) then WriteLn('Sorry, the age2.displayImage(); // loading necessary im-
driver is too young to drive.') else FRealCar.DriveCar(); age2.displayImage(); // loading unnecessary im-
end; end. age1.displayImage(); // loading unnecessary } }

Usage The program’s output is:

program Project1; {$APPTYPE Console} uses De- Loading HiRes_10MB_Photo1 Displaying
signPattern.Proxy in 'DesignPattern.Proxy.pas’; begin HiRes_10MB_Photo1 Displaying HiRes_10MB_Photo1
TProxyCar.New(TDriver.New(16)).DriveCar; TProxy- Loading HiRes_10MB_Photo2 Displaying
Car.New(TDriver.New(25)).DriveCar; end. HiRes_10MB_Photo2 Displaying HiRes_10MB_Photo2
Displaying HiRes_10MB_Photo1
Output
Sorry, the driver is too young to drive. Car has been 3.9.3 See also
driven!
• Composite pattern

Java • Decorator pattern

• Lazy initialization
The following Java example illustrates the “virtual proxy”
pattern. The ProxyImage class is used to access a remote
method. 3.9.4 References
The example creates first an interface against which the
pattern creates the classes. This interface contains only 3.9.5 External links
one method to display the image, called displayImage(),
that has to be coded by all classes implementing it. • Proxy pattern in UML and in LePUS3 (a formal
The proxy class ProxyImage is running on another sys- modelling language)
tem than the real image class itself and can represent the • Take control with the Proxy design pattern by David
real image RealImage over there. The image information Geary, JavaWorld.com
is accessed from the disk. Using the proxy pattern, the
code of the ProxyImage avoids multiple loading of the • PerfectJPattern Open Source Project, Provides
image, accessing it from the other system in a memory- componentized implementation of the Proxy Pat-
saving manner. It should be noted, however, that the lazy tern in Java
loading demonstrated in this example is not part of the
proxy pattern, but is merely an advantage made possible • Adapter vs. Proxy vs. Facade Pattern Comparison
by the use of the proxy. • Proxy Design Pattern
interface Image { public void displayImage(); } // On
• Proxy pattern C++ implementation example
System A class RealImage implements Image { private
String filename = null; /** * Constructor * @param • Proxy pattern description from the Portland Pattern
filename */ public RealImage(final String filename) Repository
{ this.filename = filename; loadImageFromDisk(); }
/** * Loads the image from the disk */ private void
loadImageFromDisk() { System.out.println(“Loading "
+ filename); } /** * Displays the image */ public void
displayImage() { System.out.println(“Displaying " + file-
name); } } // On System B class ProxyImage implements
Image { private RealImage image = null; private String
filename = null; /** * Constructor * @param filename */
public ProxyImage(final String filename) { this.filename
= filename; } /** * Displays the image */ public void
displayImage() { if (image == null) { image = new
RealImage(filename); } image.displayImage(); } } class
ProxyExample { /** * Test method */ public static void
main(final String[] arguments) { final Image image1 =
new ProxyImage(“HiRes_10MB_Photo1”); final Image
image2 = new ProxyImage(“HiRes_10MB_Photo2”);
image1.displayImage(); // loading necessary im-
Chapter 4

Behavioral patterns

4.1 Behavioral pattern • Scheduled-task pattern: A task is scheduled to be

In software engineering, behavioral design patterns
are design patterns that identify common communication
patterns between objects and realize these patterns. By
doing so, these patterns increase flexibility in carrying out
this communication.
Examples of this type of design pattern include:
• Chain of responsibility pattern: Command objects
are handled or passed on to other objects by logic-
containing processing objects
• Command pattern: Command objects encapsulate
an action and its parameters
• “Externalize the Stack": Turn a recursive function
into an iterative one that uses a stack[1]
• Interpreter pattern: Implement a specialized com-
puter language to rapidly solve a specific set of prob-
lems
performed at a particular interval or clock time (used
in real-time computing)
• Single-serving visitor pattern: Optimise the imple-
mentation of a visitor that is allocated, used only
once, and then deleted
• Specification pattern: Recombinable business logic
in a boolean fashion
• State pattern: A clean way for an object to partially
change its type at runtime
• Strategy pattern: Algorithms can be selected on the
fly
• Template method pattern: Describes the program
skeleton of a program
• Visitor pattern: A way to separate an algorithm from
an object

• Iterator pattern: Iterators are used to access the el-

ements of an aggregate object sequentially without
4.1.1 See also
exposing its underlying representation

• Mediator pattern: Provides a unified interface to a • Concurrency pattern

set of interfaces in a subsystem
• Creational pattern
• Memento pattern: Provides the ability to restore an
object to its previous state (rollback) • Structural pattern
• Null Object pattern: Designed to act as a default
value of an object
4.1.2 References
• Observer pattern: a.k.a. Publish/Subscribe or Event
Listener. Objects register to observe an event that [1] “Externalize The Stack”. c2.com. 2010-01-19. Archived
may be raised by another object from the original on 2010-01-19. Retrieved 2012-05-21.

• Weak reference pattern: De-couple an ob-
server from an observable[2]
• Protocol stack: Communications are handled
by multiple layers, which form an encapsulation
hierarchy[3]
[2] Nakashian, Ashod (2004-04-11). “Weak Reference Pat-
tern”. c2.com. Archived from the original on 2004-04-
11. Retrieved 2012-05-21.
[3] “Protocol Stack”. c2.com. 2006-09-05. Archived from
the original on 2006-09-05. Retrieved 2012-05-21.

51
52 CHAPTER 4. BEHAVIORAL PATTERNS

4.2 Chain-of-responsibility pattern PresidentPPower extends PurchasePower { protected

double getAllowable() { return BASE * 60; } protected
In object-oriented design, the chain-of-responsibility String getRole() { return “President"; } }
pattern is a design pattern consisting of a source of
command objects and a series of processing objects.[1] The following code defines the PurchaseRequest class
Each processing object contains logic that defines the that keeps the request data in this example.
types of command objects that it can handle; the rest
class PurchaseRequest { private double amount; private
are passed to the next processing object in the chain. A
String purpose; public PurchaseRequest(double amount,
mechanism also exists for adding new processing objects
String purpose) { this.amount = amount; this.purpose
to the end of this chain.
= purpose; } public double getAmount() { return
In a variation of the standard chain-of-responsibility this.amount; } public void setAmount(double amount)
model, some handlers may act as dispatchers, capable of { this.amount = amount; } public String getPurpose()
sending commands out in a variety of directions, form- { return this.purpose; } public void setPurpose(String
ing a tree of responsibility. In some cases, this can oc- purpose) { this.purpose = purpose; } }
cur recursively, with processing objects calling higher-up
processing objects with commands that attempt to solve
In the following usage example, the successors are set as
some smaller part of the problem; in this case recursion
follows: Manager -> Director -> Vice President -> Pres-
continues until the command is processed, or the entire
ident
tree has been explored. An XML interpreter might work
in this manner. class CheckAuthority { public static void main(String[]
args) { ManagerPPower manager = new ManagerP-
This pattern promotes the idea of loose coupling.
Power(); DirectorPPower director = new DirectorP-
Power(); VicePresidentPPower vp = new VicePres-
4.2.1 Example identPPower(); PresidentPPower president = new
PresidentPPower(); manager.setSuccessor(director);
Java example director.setSuccessor(vp); vp.setSuccessor(president);
// Press Ctrl+C to end. try { while (true) { Sys-
Below is an example of this pattern in Java. In this ex- tem.out.println(“Enter the amount to check who should
ample we have different roles, each having a fixed pur- approve your expenditure.”); System.out.print(">"); dou-
chasing limit and a successor. Every time a user in a role ble d = Double.parseDouble(new BufferedReader(new
receives a purchase request that exceeds his or her limit, InputStreamReader(System.in)).readLine()); man-
the request is passed to his or her successor. ager.processRequest(new PurchaseRequest(d, “Gen-
eral”)); } } catch (Exception exc) { System.exit(1); } } }
The PurchasePower abstract class with the abstract
method processRequest.
abstract class PurchasePower { protected static final
double BASE = 500; protected PurchasePower succes- C# example
sor; abstract protected double getAllowable(); abstract
protected String getRole(); public void setSucces-
This C# examples uses the logger application to select
sor(PurchasePower successor) { this.successor = suc- different sources based on the log level;
cessor; } public void processRequest(PurchaseRequest
request){ if (request.getAmount() < this.getAllowable()) namespace ChainOfResponsibility { [Flags] public enum
{ System.out.println(this.getRole() + " will approve $" LogLevel { None = 0, // 0 Info = 1, // 1 Debug = 2, // 10
+ request.getAmount()); } else if (successor != null) { Warning = 4, // 100 Error = 8, // 1000 FunctionalMes-
successor.processRequest(request); } } } sage = 16, // 10000 FunctionalError = 32, // 100000 All
= 63 // 111111 } /// <summary> /// Abstract Handler in
chain of responsibility pattern. /// </summary> public
Four implementations of the abstract class above: Man- abstract class Logger { protected LogLevel logMask; //
ager, Director, Vice President, President The next Handler in the chain protected Logger next;
class ManagerPPower extends PurchasePower { pro- public Logger(LogLevel mask) { this.logMask = mask;
tected double getAllowable() { return BASE * 10; } } /// <summary> /// Sets the Next logger to make a
protected String getRole() { return “Manager"; } } class list/chain of Handlers. /// </summary> public Logger
DirectorPPower extends PurchasePower { protected SetNext(Logger nextlogger) { next = nextlogger; return
double getAllowable() { return BASE * 20; } protected nextlogger; } public void Message(string msg, LogLevel
String getRole() { return “Director"; } } class Vi- severity) { if ((severity & logMask) != 0) //True only if
cePresidentPPower extends PurchasePower { protected all logMask bits are set in severity { WriteMessage(msg);
double getAllowable() { return BASE * 40; } protected } if (next != null) { next.Message(msg, severity); }
String getRole() { return “Vice President"; } } class } abstract protected void WriteMessage(string msg);
4.2. CHAIN-OF-RESPONSIBILITY PATTERN
} public class ConsoleLogger : Logger { public
ConsoleLogger(LogLevel mask) : base(mask) { }
protected override void WriteMessage(string msg) {
Console.WriteLine(“Writing to console: " + msg); } }
public class EmailLogger : Logger { public EmailLog-
ger(LogLevel mask) : base(mask) { } protected override
void WriteMessage(string msg) { // Placeholder for mail
send logic, usually the email configurations are saved in
config file. Console.WriteLine(“Sending via email: " +
msg); } } class FileLogger : Logger { public FileLog-
ger(LogLevel mask) : base(mask) { } protected override
void WriteMessage(string msg) { // Placeholder for File
writing logic Console.WriteLine(“Writing to Log File:
" + msg); } } public class Program { public static void
Main(string[] args) { // Build the chain of responsibility
Logger logger, logger1, logger2; logger = new ConsoleL-
ogger(LogLevel.All); logger1 = logger.SetNext(new
EmailLogger(LogLevel.FunctionalMessage
LogLevel.FunctionalError)); logger2 = log-
ger1.SetNext(new FileLogger(LogLevel.Warning
| LogLevel.Error)); // Handled by ConsoleLog-
ger since the console has a loglevel of all log-
ger.Message(“Entering function ProcessOrder().”,
LogLevel.Debug); logger.Message(“Order record re-
trieved.”, LogLevel.Info); // Handled by ConsoleLogger
and FileLogger since filelogger implements Warning
& Error logger.Message(“Customer Address details
missing in Branch DataBase.”, LogLevel.Warning);
logger.Message(“Customer Address details miss-
ing in Organization DataBase.”, LogLevel.Error); //
Handled by ConsoleLogger and EmailLogger as it
implements functional error logger.Message(“Unable
to Process Order ORD1 Dated D1 For Customer
C1.”, LogLevel.FunctionalError); // Handled by Con-
soleLogger and EmailLogger logger.Message(“Order
Dispatched.”, LogLevel.FunctionalMessage); } } } /*
Output Writing to console: Entering function Proces-
sOrder(). Writing to console: Order record retrieved.
Writing to console: Customer Address details missing
in Branch DataBase. Writing to Log File: Customer
Address details missing in Branch DataBase. Writing to
console: Customer Address details missing in Organiza-
tion DataBase. Writing to Log File: Customer Address
details missing in Organization DataBase. Writing to
console: Unable to Process Order ORD1 Dated D1 For
Customer C1. Sending via email: Unable to Process
Order ORD1 Dated D1 For Customer C1. Writing to
console: Order Dispatched. Sending via email: Order
Dispatched. */
Crystal example
enum LogLevel None, Info, Debug, Warning, Er-
ror, FunctionalMessage, FunctionalError, All end
abstract class Logger protected getter log_levels pro-
tected getter next : Logger | Nil def initialize(*levels)
@log_levels = [] of LogLevel levels.each do |level|
53
@log_levels << level end end def set_next(next_logger
: Logger) @next = next_logger end def message(msg
: String, severity : LogLevel) write_message(msg)
if @log_levels.includes?(LogLevel::All)
|| @log_levels.includes?(severity)
@next.try(&.message(msg, severity)) if @next end
abstract def write_message(msg : String) end class
ConsoleLogger < Logger def write_message(msg :
String) puts “Writing to console: #{msg}" end end
class EmailLogger < Logger def write_message(msg
: String) puts “Sending via email: #{msg}" end end
class FileLogger < Logger def write_message(msg :
String) puts “Writing to Log File: #{msg}" end end
# Program # Build the chain of responsibility logger
= ConsoleLogger.new(LogLevel::All) logger1 = log-
ger.set_next(EmailLogger.new(LogLevel::FunctionalMessage,
LogLevel::FunctionalError)) logger2 = log-
| ger1.set_next(FileLogger.new(LogLevel::Warning,
LogLevel::Error)) # Handled by ConsoleLog-
ger since the console has a loglevel of all log-
ger.message(“Entering function ProcessOrder().”,
LogLevel::Debug) logger.message(“Order record re-
trieved.”, LogLevel::Info) # Handled by ConsoleLogger
and FileLogger since filelogger implements Warning
& Error logger.message(“Customer Address details
missing in Branch DataBase.”, LogLevel::Warning)
logger.message(“Customer Address details miss-
ing in Organization DataBase.”, LogLevel::Error) #
Handled by ConsoleLogger and EmailLogger as it
implements functional error logger.message(“Unable
to Process Order ORD1 Dated D1 For Customer
C1.”, LogLevel::FunctionalError) # Handled by Con-
soleLogger and EmailLogger logger.message(“Order
Dispatched.”, LogLevel::FunctionalMessage)
Output
Writing to console: Entering function ProcessOrder().
Writing to console: Order record retrieved. Writing to
console: Customer Address details missing in Branch
DataBase. Writing to Log File: Customer Address details
missing in Branch DataBase. Writing to console: Cus-
tomer Address details missing in Organization DataBase.
Writing to Log File: Customer Address details missing
in Organization DataBase. Writing to console: Unable to
Process Order ORD1 Dated D1 For Customer C1. Send-
ing via email: Unable to Process Order ORD1 Dated D1
For Customer C1. Writing to console: Order Dispatched.
Sending via email: Order Dispatched.
4.2.2 Implementations
Cocoa and Cocoa Touch
The Cocoa and Cocoa Touch frameworks, used for
OS X and iOS applications respectively, actively use
the chain-of-responsibility pattern for handling events.
Objects that participate in the chain are called re-
54 CHAPTER 4. BEHAVIORAL PATTERNS

sponder objects, inheriting from the NSResponder about a concrete command, it knows only about com-
(OS X)/UIResponder (iOS) class. All view objects mand interface. Both an invoker object and several com-
(NSView/UIView), view controller objects (NSView- mand objects are held by a client object. The client de-
Controller/UIViewController), window objects (NSWin- cides which commands to execute at which points. To
dow/UIWindow), and the application object (NSAppli- execute a command, it passes the command object to the
cation/UIApplication) are responder objects. invoker object.
Typically, when a view receives an event which it can't Using command objects makes it easier to construct gen-
handle, it dispatches it to its superview until it reaches the
eral components that need to delegate, sequence or ex-
view controller or window object. If the window can't ecute method calls at a time of their choosing without
handle the event, the event is dispatched to the applicationthe need to know the class of the method or the method
object, which is the last object in the chain. For example: parameters. Using an invoker object allows bookkeep-
ing about command executions to be conveniently per-
• On OS X, moving a textured window with the mouse formed, as well as implementing different modes for
can be done from any location (not just the title bar), commands, which are managed by the invoker object,
unless on that location there’s a view which handles without the need for the client to be aware of the exis-
dragging events, like slider controls. If no such view tence of bookkeeping or modes.
(or superview) is there, dragging events are sent up
the chain to the window which does handle the drag- 4.3.1 Uses
ging event.

• On iOS, it’s typical to handle view events in the view Notation: UML
Caller Command

controller which manages the view hierarchy, in- execute()

stead of subclassing the view itself. Since a view

Receiver
controller lies in the responder chain after all of its Client ConcreteCommand
action()
managed subviews, it can intercept any view events state

execute() receiver.action()

and handle them.

UML diagram of the command pattern

4.2.3 See also
• Software design pattern
• Single responsibility principle
4.2.4 References
[1] http://www.blackwasp.co.uk/ChainOfResponsibility.
aspx
4.3 Command pattern
In object-oriented programming, the command pattern
is a behavioral design pattern in which an object is used to
encapsulate all information needed to perform an action
or trigger an event at a later time. This information in-
cludes the method name, the object that owns the method
and values for the method parameters.
Four terms always associated with the command pattern
are command, receiver, invoker and client. A command
object knows about receiver and invokes a method of the
receiver. Values for parameters of the receiver method
are stored in the command. The receiver then does the Multi-level undo If all user actions in a program are
work. An invoker object knows how to execute a com-
mand, and optionally does bookkeeping about the com-
mand execution. The invoker does not know anything
Command objects are useful for implementing
GUI buttons and menu items In Swing and Borland
Delphi programming, an Action is a command ob-
ject. In addition to the ability to perform the desired
command, an Action may have an associated icon,
keyboard shortcut, tooltip text, and so on. A toolbar
button or menu item component may be completely
initialized using only the Action object.
Macro recording If all user actions are represented by
command objects, a program can record a sequence
of actions simply by keeping a list of the command
objects as they are executed. It can then “play back”
the same actions by executing the same command
objects again in sequence. If the program embeds a
scripting engine, each command object can imple-
ment a toScript() method, and user actions can then
be easily recorded as scripts.
Mobile Code Using languages such as Java where code
can be streamed/slurped from one location to an-
other via URLClassloaders and Codebases the com-
mands can enable new behavior to be delivered to
remote locations (EJB Command, Master Worker)
implemented as command objects, the program can
keep a stack of the most recently executed com-
mands. When the user wants to undo a command,
4.3. COMMAND PATTERN
the program simply pops the most recent command synonyms, and implementations that may obscure the
object and executes its undo() method. original pattern by going well beyond it.
Networking It is possible to send whole command ob-
jects across the network to be executed on the other
machines, for example player actions in computer
games.
Parallel Processing Where the commands are written
as tasks to a shared resource and executed by many
threads in parallel (possibly on remote machines -
this variant is often referred to as the Master/Worker
pattern)
Progress bars Suppose a program has a sequence of
commands that it executes in order. If each com-
mand object has a getEstimatedDuration() method,
the program can easily estimate the total duration.
It can show a progress bar that meaningfully reflects
how close the program is to completing all the tasks.
Thread pools A typical, general-purpose thread pool
class might have a public addTask() method that
adds a work item to an internal queue of tasks wait-
ing to be done. It maintains a pool of threads that
execute commands from the queue. The items in
the queue are command objects. Typically these
objects implement a common interface such as
java.lang.Runnable that allows the thread pool to
execute the command even though the thread pool
class itself was written without any knowledge of the
specific tasks for which it would be used.
Transactional behavior Similar to undo, a database
engine or software installer may keep a list of oper-
ations that have been or will be performed. Should
one of them fail, all others can be reversed or dis-
carded (usually called rollback). For example, if two
database tables that refer to each other must be up-
dated, and the second update fails, the transaction
can be rolled back, so that the first table does not
now contain an invalid reference.
Wizards Often a wizard presents several pages of con-
figuration for a single action that happens only when
the user clicks the “Finish” button on the last page.
In these cases, a natural way to separate user in-
terface code from application code is to implement
the wizard using a command object. The command
object is created when the wizard is first displayed.
Each wizard page stores its GUI changes in the com-
mand object, so the object is populated as the user
progresses. “Finish” simply triggers a call to exe-
cute(). This way, the command class will work.
4.3.2 Terminology
The terminology used to describe command pattern im-
plementations is not consistent and can therefore be con-
fusing. This is the result of ambiguity, the use of
55
1. Ambiguity.
(a) The term command is ambiguous. For exam-
ple, move up, move up may refer to a single
(move up) command that should be executed
twice, or it may refer to two commands, each
of which happens to do the same thing (move
up). If the former command is added twice
to an undo stack, both items on the stack re-
fer to the same command instance. This may
be appropriate when a command can always
be undone the same way (e.g. move down).
Both the Gang of Four and the Java example
below use this interpretation of the term com-
mand. On the other hand, if the latter com-
mands are added to an undo stack, the stack
refers to two separate objects. This may be ap-
propriate when each object on the stack must
contain information that allows the command
to be undone. For example, to undo a delete
selection command, the object may contain a
copy of the deleted text so that it can be re-
inserted, if the delete selection command must
be undone. Note that using a separate object
for each invocation of a command is also an
example of the chain of responsibility pattern.
(b) The term execute is also ambiguous. It may
refer to running the code identified by the
command object’s execute method. However,
in Microsoft’s Windows Presentation Founda-
tion a command is considered to have been ex-
ecuted when the command’s execute method
has been invoked, but that does not necessarily
mean that the application code has run. That
occurs only after some further event process-
ing.
2. Synonyms and homonyms.
(a) Client, Source, Invoker: the button, toolbar
button, or menu item clicked, the shortcut key
pressed by the user.
(b) Command Object, Routed Command Ob-
ject, Action Object: a singleton object (e.g.
there is only one CopyCommand object),
which knows about shortcut keys, button im-
ages, command text, etc. related to the com-
mand. A source/invoker object calls the Com-
mand/Action object’s execute/performAction
method. The Command/Action object no-
tifies the appropriate source/invoker objects
when the availability of a command/action has
changed. This allows buttons and menu items
to become inactive (grayed out) when a com-
mand/action cannot be executed/performed.
56 CHAPTER 4. BEHAVIORAL PATTERNS

(c) Receiver, Target Object: the object that is object that identifies the target and the appli-
about to be copied, pasted, moved, etc. The cation code, which is executed at that point.
receiver object owns the method that is called
by the command’s execute method. The re-
ceiver is typically also the target object. For 4.3.3 Example
example, if the receiver object is a cursor
and the method is called moveUp, then one Consider a “simple” switch. In this example we configure
would expect that the cursor is the target of the Switch with two commands: to turn the light on and
the moveUp action. On the other hand, if the to turn the light off.
code is defined by the command object itself, A benefit of this particular implementation of the com-
the target object will be a different object en- mand pattern is that the switch can be used with any de-
tirely. vice, not just a light - the Switch in the following exam-
(d) Command Object, routed event argu- ple turns a light on and off, but the Switch’s constructor
ments, event object: the object that is passed is able to accept any subclasses of Command for its two
from the source to the Command/Action ob- parameters. For example, you could configure the Switch
ject, to the Target object to the code that does to start an engine.
the work. Each button click or shortcut key
results in a new command/event object. Some
implementations add more information to the C#
command/event object as it is being passed
from one object (e.g. CopyCommand) to an- The following code is an implementation of Command
other (e.g. document section). Other im- pattern in C#.
plementations put command/event objects in namespace CommandPattern { using System; pub-
other event objects (like a box inside a bigger lic interface ICommand { void Execute(); } /* The
box) as they move along the line, to avoid nam- Invoker class */ public class Switch { ICommand
ing conflicts. (See also chain of responsibility _closedCommand; ICommand _openedCommand;
pattern). public Switch(ICommand closedCommand, ICom-
(e) Handler, ExecutedRoutedEventHandler, mand openedCommand) { this._closedCommand =
method, function: the actual code that closedCommand; this._openedCommand = opened-
does the copying, pasting, moving, etc. In Command; } //close the circuit/power on public
some implementations the handler code void Close() { this._closedCommand.Execute(); }
is part of the command/action object. In //open the circuit/power off public void Open() {
other implementations the code is part of this._openedCommand.Execute(); } } /* An interface
the Receiver/Target Object, and in yet other that defines actions that the receiver can perform
implementations the handler code is kept */ public interface ISwitchable { void PowerOn();
separate from the other objects. void PowerOff(); } /* The Receiver class */ public
class Light : ISwitchable { public void PowerOn() {
(f) Command Manager, Undo Manager,
Console.WriteLine(“The light is on”); } public void
Scheduler, Queue, Dispatcher, Invoker: an
PowerOff() { Console.WriteLine(“The light is off”);
object that puts command/event objects on
} } /* The Command for turning on the device -
an undo stack or redo stack, or that holds on
ConcreteCommand #1 */ public class CloseSwitchCom-
to command/event objects until other objects
mand : ICommand { private ISwitchable _switchable;
are ready to act on them, or that routes the
public CloseSwitchCommand(ISwitchable switchable)
command/event objects to the appropriate
{ _switchable = switchable; } public void Execute()
receiver/target object or handler code.
{ _switchable.PowerOn(); } } /* The Command for
3. Implementations that go well beyond the original turning off the device - ConcreteCommand #2 */
command pattern. public class OpenSwitchCommand : ICommand {
private ISwitchable _switchable; public OpenSwitch-
(a) Microsoft’s Windows Presentation Foundation Command(ISwitchable switchable) { _switchable
(WPF), introduces routed commands, which = switchable; } public void Execute() { _switch-
combine the command pattern with event pro- able.PowerOff(); } } /* The test class or client */
cessing. As a result, the command object no internal class Program { public static void Main(string[]
longer contains a reference to the target ob- arguments) { string argument = arguments.Length > 0
ject nor a reference to the application code. ? arguments[0].ToUpper() : null; ISwitchable lamp =
Instead, invoking the command object’s exe- new Light(); //Pass reference to the lamp instance to
cute command results in a so-called Executed each command ICommand switchClose = new Clos-
Routed Event that during the event’s tunneling eSwitchCommand(lamp); ICommand switchOpen =
or bubbling may encounter a so-called binding new OpenSwitchCommand(lamp); //Pass reference to
4.3. COMMAND PATTERN
instances of the Command objects to the switch Switch
@switch = new Switch(switchClose, switchOpen); if
(argument == “ON”) { // Switch (the Invoker) will in-
voke Execute() (the Command) on the command object
- _closedCommand.Execute(); @switch.Close(); } else
if (argument == “OFF”) { //Switch (the Invoker) will
invoke the Execute() (the Command) on the command
object - _openedCommand.Execute(); @switch.Open();
} else { Console.WriteLine(“Argument \"ON\" or
\"OFF\" is required.”); } } } }
Java
import java.util.List; import java.util.ArrayList; /**
The Command interface */ public interface Command
{ void execute(); } /** The Invoker class */ public
class Switch { private List<Command> history = new
ArrayList<Command>(); public void storeAndExe-
cute(final Command cmd) { this.history.add(cmd);
// optional cmd.execute(); } } /** The Receiver
class */ public class Light { public void turnOn() {
System.out.println(“The light is on”); } public void
turnOff() { System.out.println(“The light is off”); }
} /** The Command for turning on the light - Con-
creteCommand #1 */ public class FlipUpCommand
implements Command { private Light theLight; public
FlipUpCommand(final Light light) { this.theLight =
light; } @Override // Command public void execute()
{ theLight.turnOn(); } } /** The Command for turning
off the light - ConcreteCommand #2 */ public class
FlipDownCommand implements Command { private
Light theLight; public FlipDownCommand(final Light
light) { this.theLight = light; } @Override // Command
public void execute() { theLight.turnOff(); } } /* The
test class or client */ public class PressSwitch { public
static void main(final String[] arguments){ // Check
number of arguments if (arguments.length != 1) {
System.err.println(“Argument \"ON\" or \"OFF\" is
required.”); System.exit(−1); } final Light lamp =
new Light(); final Command switchUp = new FlipUp-
Command(lamp); final Command switchDown = new
FlipDownCommand(lamp); final Switch mySwitch
= new Switch(); switch(arguments[0]) { case “ON":
mySwitch.storeAndExecute(switchUp); break; case
“OFF": mySwitch.storeAndExecute(switchDown);
break; default: System.err.println(“Argument \"ON\" or
\"OFF\" is required.”); System.exit(−1); } } }
Java 8 Using a functional interface.
/** * The Command functional interface.<br/> */
@FunctionalInterface public interface Command
{ public void apply(); } /** * The Command-
Factory class.<br/> */ import java.util.HashMap;
import java.util.stream.Collectors; public final class
CommandFactory { private final HashMap<String,
57
Command> commands; private CommandFactory()
{ commands = new HashMap<String,Command>();
} public void addCommand(final String name, fi-
nal Command command) { commands.put(name,
command); } public void executeCommand(String
name) { if (commands.containsKey(name))
{ commands.get(name).apply(); } }
public void listCommands() { Sys-
tem.out.println(“Enabled commands: " + com-
mands.keySet().stream().collect(Collectors.joining(",
"))); } /* Factory pattern */ public static Command-
Factory init() { final CommandFactory cf = new
CommandFactory(); // commands are added here using
lambdas. It is also possible to dynamically add com-
mands without editing the code. cf.addCommand(“Light
on”, () -> System.out.println(“Light turned
on”)); cf.addCommand(“Light off”, () -> Sys-
tem.out.println(“Light turned off”)); return cf; } }
public final class Main { public static void main(final
String[] arguments) { final CommandFactory cf =
CommandFactory.init(); cf.executeCommand(“Light
on”); cf.listCommands(); } }
Python
The following code is an implementation of Command
pattern in Python.
class Switch(object): """The INVOKER class"""
def __init__(self): self._history = () @property def
history(self): return self._history def execute(self,
command): self._history = self._history + (com-
mand,) command.execute() class Command(object):
"""The COMMAND interface""" def __init__(self,
obj): self._obj = obj def execute(self): raise NotIm-
plementedError class TurnOnCommand(Command):
"""The COMMAND for turning on the light""" def
execute(self): self._obj.turn_on() class TurnOffCom-
mand(Command): """The COMMAND for turning
off the light""" def execute(self): self._obj.turn_off()
class Light(object): """The RECEIVER class""" def
turn_on(self): print(“The light is on”) def turn_off(self):
print(“The light is off”) class LightSwitchClient(object):
"""The CLIENT class""" def __init__(self): self._lamp
= Light() self._switch = Switch() @property def
switch(self): return self._switch def press(self,
cmd): cmd = cmd.strip().upper() if cmd == “ON":
self._switch.execute(TurnOnCommand(self._lamp))
elif cmd == “OFF":
self._switch.execute(TurnOffCommand(self._lamp))
else: print(“Argument 'ON' or 'OFF' is required.”) #
Execute if this file is run as a script and not imported as a
module if __name__ == "__main__": light_switch
= LightSwitchClient() print(“Switch ON test.”)
light_switch.press(“ON”) print(“Switch OFF test.”)
light_switch.press(“OFF”) print(“Invalid Command
test.”) light_switch.press("****") print(“Command
58 CHAPTER 4. BEHAVIORAL PATTERNS

history:") print(light_switch.switch.history) JavaScript

The following code is an implementation of Command

pattern in JavaScript.
/* The Invoker function */ “use strict"; class Switch {
Ruby constructor() { this._commands = []; } storeAndEx-
ecute(command) { this._commands.push(command);
command.execute(); } } class Light { turnOn() { con-
# Invoker class Switch attr_reader :history def exe- sole.log('turn on') } turnOff() { console.log('turn
cute(cmd) @history ||= [] @history << cmd.execute end off') } } class FlipDownCommand { construc-
end # Command Interface class Command attr_reader tor(light) { this._light = light; } execute() {
:obj def initialize(obj) @obj = obj end def execute this._light.turnOff(); } } class FlipUpCommand {
raise NotImplementedError end end # Command for constructor(light) { this._light = light; } execute()
turning on class TurnOnCommand < Command def { this._light.turnOn(); } } var light = new Light();
execute obj.turn_on end end # Command for turning var switchUp = new FlipUpCommand(light); var
off class TurnOffCommand < Command def execute switchDown = new FlipDownCommand(light); var
obj.turn_off end end # Receiver class Light def turn_on s = new Switch(); s.storeAndExecute(switchUp);
'the light is on' end def turn_off 'the light is off' end end s.storeAndExecute(switchDown);
# Client class LightSwitchClient attr_reader :switch def
initialize @lamp = Light.new @switch = Switch.new
end def switch_for(cmd) case cmd when 'on' then
@switch.execute(TurnOnCommand.new(@lamp)) when Coffeescript
'off' then @switch.execute(TurnOffCommand.new(@lamp))
else puts 'Sorry, I so sorry' end end end client The following code is an implementation of Command
= LightSwitchClient.new client.switch_for('on') pattern in Coffeescript
client.switch_for('off') client.switch.history #=> ['the
# The Invoker function class Switch _commands
light is on', 'the light is off']
= [] storeAndExecute: (command) -> _com-
mands.push(command) command.execute() # The Re-
ceiver function class Light turnOn: -> console.log ('turn
on') turnOff: -> console.log ('turn off') # The Command
for turning on the light - ConcreteCommand #1 class
FlipUpCommand constructor: (@light) -> execute: ->
Scala
@light.turnOn() # The Command for turning off the light
- ConcreteCommand #2 class FlipDownCommand con-
/* The Command interface */ trait Command { def structor: (@light) -> execute: -> @light.turnOff() light
execute() } /* The Invoker class */ class Switch { private = new Light() switchUp = new FlipUpCommand(light)
var history: List[Command] = Nil def storeAndEx- switchDown = new FlipDownCommand(light) s
ecute(cmd: Command) { cmd.execute() this.history = new Switch() s.storeAndExecute(switchUp)
:+= cmd } } /* The Receiver class */ class Light { s.storeAndExecute(switchDown)
def turnOn() = println(“The light is on”) def turnOff()
= println(“The light is off”) } /* The Command for
turning on the light - ConcreteCommand #1 */ class
FlipUpCommand(theLight: Light) extends Command { 4.3.4 See also
def execute() = theLight.turnOn() } /* The Command
for turning off the light - ConcreteCommand #2 */ • Batch queue
class FlipDownCommand(theLight: Light) extends
Command { def execute() = theLight.turnOff() } /* • Closure
The test class or client */ object PressSwitch { def
main(arguments: Array[String]) { val lamp = new • Command queue
Light() val switchUp = new FlipUpCommand(lamp) val
switchDown = new FlipDownCommand(lamp) val s = • Function object
new Switch() try { arguments(0).toUpperCase match
• Job scheduler
{ case “ON” => s.storeAndExecute(switchUp) case
“OFF” => s.storeAndExecute(switchDown) case _ => • Model-view-controller
println(“Argument \"ON\" or \"OFF\" is required.”)
} } catch { case e: Exception => println(“Arguments • Priority queue
required.”) } } }
• Software design pattern
4.4. INTERPRETER PATTERN 59

4.3.5 References 4.4.3 Example

• Freeman, E; Sierra, K; Bates, B (2004). Head First BNF
Design Patterns. O'Reilly.
The following Backus–Naur form example illustrates the
• GoF - Design Patterns interpreter pattern. The grammar
expression ::= plus | minus | variable | number plus ::=
4.3.6 External links expression expression '+' minus ::= expression expression
'-' variable ::= 'a' | 'b' | 'c' | ... | 'z' digit = '0' | '1' | ... | '9'
• http://c2.com/cgi/wiki?CommandPattern number ::= digit | digit number

• http://www.javaworld.com/javaworld/javatips/
defines a language that contains Reverse Polish Notation
jw-javatip68.html
expressions like:
ab+abc+-ab+ca--
4.4 Interpreter pattern
C#
In computer programming, the interpreter pattern is a
design pattern that specifies how to evaluate sentences in This structural code demonstrates the Interpreter pat-
a language. The basic idea is to have a class for each sym- terns, which using a defined grammar, provides the in-
bol (terminal or nonterminal) in a specialized computer terpreter that processes parsed statements.
language. The syntax tree of a sentence in the language is
namespace DesignPatterns.Interpreter { // “Context”
an instance of the composite pattern and is used to eval-
class Context { } // “AbstractExpression” abstract
uate (interpret) the sentence for a client.[1]:243 See also
class AbstractExpression { public abstract void In-
Composite pattern. terpret(Context context); } // “TerminalExpression”
class TerminalExpression : AbstractExpression {
public override void Interpret(Context context) { Con-
4.4.1 Uses sole.WriteLine(“Called Terminal.Interpret()"); } } //
“NonterminalExpression” class NonterminalExpression
• Specialized database query languages such as SQL.
: AbstractExpression { public override void Inter-
• Specialized computer languages that are often used pret(Context context) { Console.WriteLine(“Called
to describe communication protocols. Nonterminal.Interpret()"); } } class MainApp { static
void Main() { var context = new Context(); // Usually
• Most general-purpose computer languages actually a tree var list = new List<AbstractExpression>(); //
incorporate several specialized languages. Populate 'abstract syntax tree' list.Add(new Terminal-
Expression()); list.Add(new NonterminalExpression());
list.Add(new TerminalExpression()); list.Add(new
4.4.2 Structure TerminalExpression()); // Interpret foreach (AbstractEx-
pression exp in list) { exp.Interpret(context); } } } }

Context Notation: UML

Java
Client
Following the interpreter pattern there is a class for each
AbstractExpression
grammar rule.
import java.util.Map; interface Expression { public int in-
Interpret(Context)
terpret(final Map<String, Expression> variables); } class
Number implements Expression { private int number;
public Number(final int number) { this.number = num-
ber; } public int interpret(final Map<String, Expression>
variables) { return number; } } class Plus implements
TerminalExpression Expression { Expression leftOperand; Expression
NonterminalExpression
rightOperand; public Plus(final Expression left, final Ex-
Interpret(Context) pression Interpret(Context)
right) { leftOperand = left; rightOperand = right;
} public int interpret(final Map<String, Expression>
variables) { return leftOperand.interpret(variables) +
60 CHAPTER 4. BEHAVIORAL PATTERNS

rightOperand.interpret(variables); } } class Minus imple- • Domain-specific language

ments Expression { Expression leftOperand; Expression
rightOperand; public Minus(final Expression left, final • Interpreter (computing)
Expression right) { leftOperand = left; rightOperand =
right; } public int interpret(final Map<String, Expres-
4.4.5 References
sion> variables) { return leftOperand.interpret(variables)
- rightOperand.interpret(variables); } } class Variable [1] Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlis-
implements Expression { private String name; public sides, John (1994). Design Patterns: Elements of Reusable
Variable(final String name) { this.name = name; } Object-Oriented Software. Addison-Wesley. ISBN 0-201-
public int interpret(final Map<String, Expression> 63361-2.
variables) { if (null == variables.get(name)) return
0; // Either return new Number(0). return vari-
ables.get(name).interpret(variables); } } 4.4.6 External links
• Interpreter implementation in Ruby
While the interpreter pattern does not address
parsing[1]:247 a parser is provided for completeness. • Interpreter implementation in C++
import java.util.Map; import java.util.Stack; class • SourceMaking tutorial
Evaluator implements Expression { private Ex-
pression syntaxTree; public Evaluator(final String • Interpreter pattern description from the Portland
expression) { final Stack<Expression> expres- Pattern Repository
sionStack = new Stack<Expression>(); for (fi-
nal String token : expression.split(" ")) { if (to-
ken.equals("+")) { final Expression subExpression = new 4.5 Iterator pattern
Plus(expressionStack.pop(), expressionStack.pop());
expressionStack.push(subExpression); } else if In object-oriented programming, the iterator pattern is
(token.equals("-")) { // it’s necessary remove first a design pattern in which an iterator is used to traverse
the right operand from the stack final Expression right a container and access the container’s elements. The it-
= expressionStack.pop(); // ..and after the left one erator pattern decouples algorithms from containers; in
final Expression left = expressionStack.pop(); final some cases, algorithms are necessarily container-specific
Expression subExpression = new Minus(left, right); and thus cannot be decoupled.
expressionStack.push(subExpression); } else expres-
sionStack.push(new Variable(token)); } syntaxTree For example, the hypothetical algorithm SearchForEle-
= expressionStack.pop(); } public int interpret(final ment can be implemented generally using a specified type
Map<String, Expression> context) { return syntax- of iterator rather than implementing it as a container-
Tree.interpret(context); } } specific algorithm. This allows SearchForElement to be
used on any container that supports the required type of
iterator.
Finally evaluating the expression “w x z - +" with w = 5,
x = 10, and z = 42.
import java.util.Map; import java.util.HashMap; public 4.5.1 Definition
class InterpreterExample { public static void main(final
String[] args) { final String expression = “w x z - +"; final
Evaluator sentence = new Evaluator(expression); Aggregate << create >>
Iterator

final Map<String, Expression> variables = new + iterator() + next()

+ hasNext()
HashMap<String, Expression>(); variables.put(“w”,
new Number(5)); variables.put(“x”, new Number(10));
variables.put(“z”, new Number(42)); final int result =
sentence.interpret(variables); System.out.println(result); ConcreteAggregate << create >> ConcreteIterator
}}
+
iterator() + next()
+ hasNext()

4.4.4 See also The iterator pattern

• Backus–Naur form The essence of the Iterator Factory method Pattern is

• Combinatory logic in computing to “Provide a way to access the elements of an aggre-
gate object sequentially without exposing its underlying
• Design Patterns representation.”.[1]
4.5. ITERATOR PATTERN 61

4.5.2 Language-specific implementation function reverseArrayIterator(array) { var index =

array.length - 1; return { next: () => index >= 0
Main article: Iterator ? {value: array[index--], done: false} : {done:
true} } } const it = reverseArrayIterator(['three',
'two', 'one']); console.log(it.next().value); //->
Some languages standardize syntax. C++ and Python are
'one' console.log(it.next().value); //-> 'two' con-
notable examples.
sole.log(it.next().value); //-> 'three' console.log(`Are you
done? ${it.next().done}`); //-> true
C#
Most of the time, though, what you want is to provide
.NET Framework has special interfaces that support Iterator[3] semantics on objects so that they can be iter-
a simple iteration: System.Collections.IEnumerator ated automatically via for...of loops. Some of JavaScript’s
over a non-generic collection and Sys- built-in types such as Array, Map, or Set already define
tem.Collections.Generic.IEnumerator<T> over a their own iteration behavior. You can achieve the same
generic collection. effect by defining an object’s meta @@iterator method,
C# statement foreach is designed to easily it- also referred to by Symbol.iterator. This creates an Iter-
erate through the collection that implements able object.
System.Collections.IEnumerator and/or Sys- Here’s an example of a range function that generates a
tem.Collections.Generic.IEnumerator<T> interface. list of values starting from start to end, exclusive, using a
Example of using foreach statement: regular for loop to generate the numbers:

var primes = new List<int>{ 2, 3, 5, 7, 11, 13, 17, 19}; function range(start, end) { return { [Symbol.iterator]()
long m = 1; foreach (var p in primes) m *= p; { //#A return this; }, next() { if(start < end) { return {
value: start++, done:false }; //#B } return { done: true,
value:end }; //#B } } } for(number of range(1, 5)) {
console.log(number); //-> 1, 2, 3, 4 }
C++
The iteration mechanism of built-in types, like strings,
C++ implements iterators with the semantics of pointers can also be manipulated:
in that language. In C++, a class can overload all of the
pointer operations, so an iterator can be implemented that let iter = ['I', 't', 'e', 'r', 'a', 't', 'o', 'r'][Symbol.iterator]();
acts more or less like a pointer, complete with derefer- iter.next().value; //-> I iter.next().value; //-> t
ence, increment, and decrement. This has the advantage
that C++ algorithms such as std::sort can immediately be
applied to plain old memory buffers, and that there is no PHP
new syntax to learn. However, it requires an “end” itera-
tor to test for equality, rather than allowing an iterator to PHP supports the iterator pattern via the Iterator inter-
know that it has reached the end. In C++ language, we face, as part of the standard distribution.[4] Objects that
say that an iterator models the iterator concept. implement the interface can be iterated over with the
foreach language construct.
Java Example of patterns using PHP:
<?php // BookIterator.php namespace DesignPatterns;
Java has the Iterator interface. class BookIterator implements \Iterator { private
As of Java 5, objects implementing the Iterable inter- $i_position = 0; private $booksCollection; public func-
face, which returns an Iterator from its only method, can tion __construct(BookCollection $booksCollection) {
be traversed using the enhanced for loop syntax.[2] The $this->booksCollection = $booksCollection; } public
Collection interface from the Java collections framework function current() { return $this->booksCollection-
extends Iterable. >getTitle($this->i_position); } public function key()
{ return $this->i_position; } public function next()
{ $this->i_position++; } public function rewind()
JavaScript { $this->i_position = 0; } public function valid() {
return !is_null($this->booksCollection->getTitle($this-
JavaScript, as part of ECMAScript 6, supports the itera- >i_position)); } }
tor pattern with any object that provides a next() method, <?php // BookCollection.php namespace DesignPatterns;
which returns an object with two specific properties: done class BookCollection implements \IteratorAggregate {
and value. Here’s an example that shows a reverse array private $a_titles = array(); public function getIterator()
iterator: { return new BookIterator($this); } public function
62
addTitle($string) { $this->a_titles[] = $string; } public 4.5.5 External links
function getTitle($key) { if (isset($this->a_titles[$key]))
{ return $this->a_titles[$key]; } return null; } public
function is_empty() { return empty($a_titles); } }
<?php // index.php require 'vendor/autoload.php';
use DesignPatterns\BookCollection; $booksCollec-
tion = new BookCollection(); $booksCollection-
>addTitle('Design Patterns’); $booksCollection-
>addTitle('PHP7 is the best'); $booksCollection-
>addTitle('Laravel Rules’); $booksCollection-
>addTitle('DHH Rules’); foreach($booksCollection
as $book){ var_dump($book); }
OUTPUT string(15) “Design Patterns” string(16)
“PHP7 is the best” string(13) “Laravel Rules” string(9)
“DHH Rules”
Python
Python prescribes a syntax for iterators as part of the lan-
guage itself, so that language keywords such as for work
with what Python calls sequences. A sequence has an
__iter__() method that returns an iterator object. The “it-
erator protocol” requires next() return the next element or
raise a StopIteration exception upon reaching the end of
the sequence. Iterators also provide an __iter__() method
returning themselves so that they can also be iterated over
e.g., using a for loop. Generators are available since 2.2.
In Python 3, next() was renamed __next__().[5]
4.5.3 See also
• Composite pattern
• Container (data structure)
• Design pattern (computer science)
• Iterator
• Observer pattern
4.5.4 References
[1] Gang Of Four
[2] “An enhanced for loop for the Java™ Programming Lan-
guage”. Retrieved 25 June 2013.
[3] “Iterators and generators”. Retrieved 18 March 2016.
[4] “PHP: Iterator”. Retrieved 23 June 2013.
[5] “Python v2.7.1 documentation: The Python Standard Li-
brary: 5. Built-in Types”. Retrieved 2 May 2011.
CHAPTER 4. BEHAVIORAL PATTERNS
• Object iteration in PHP
• Iterator Pattern in C#
• Iterator pattern in UML and in LePUS3 (a formal
modelling language)
• SourceMaking tutorial
• Design Patterns implementation examples tutorial
• Iterator Pattern
4.6 Mediator pattern
In software engineering, the mediator pattern defines an
object that encapsulates how a set of objects interact. This
pattern is considered to be a behavioral pattern due to the
way it can alter the program’s running behavior.
Usually a program is made up of a large number of
classes. Logic and computation is distributed among
these classes. However, as more classes are added
to a program, especially during maintenance and/or
refactoring, the problem of communication between
these classes may become more complex. This makes
the program harder to read and maintain. Furthermore,
it can become difficult to change the program, since any
change may affect code in several other classes.
With the mediator pattern, communication between ob-
jects is encapsulated within a mediator object. Ob-
jects no longer communicate directly with each other,
but instead communicate through the mediator. This re-
duces the dependencies between communicating objects,
thereby reducing coupling.
4.6.1 Definition
The mediator behavioural design pattern
The essence of the Mediator Pattern is to “define an ob-
ject that encapsulates how a set of objects interact”. It
promotes loose coupling by keeping objects from refer-
ring to each other explicitly, and it allows their interac-
tion to be varied independently.[1] Client classes can use
the mediator to send messages to other clients, and can
receive messages from other clients via an event on the
mediator class.
4.6. MEDIATOR PATTERN 63

4.6.2 Participants sageReceivedEventHandler(Receive); } private void

Receive(string message, string from) { if (from !=
Mediator - defines the interface for communication be- Name) Console.WriteLine("{0} received '{1}' from
tween Colleague objects {2}", Name, message, from); } public void Send(string
message) { _mediator.Send(message, Name); } }
ConcreteMediator - implements the Mediator interface
and coordinates communication between Colleague ob-
jects. It is aware of all of the Colleagues and their pur-
poses with regards to inter-communication. Java
Colleague - defines the interface for communication with
other Colleagues In the following example a mediator object controls the
status of three collaborating buttons: for this it contains
ConcreteColleague - implements the Colleague inter-
three methods (book(), view() and search()) that set the
face and communicates with other Colleagues through its
status of the buttons. The methods are called by each
Mediator
button upon activation (via the execute() method in each
of them).
4.6.3 Example Hence here the collaboration pattern is that each partici-
pant (here the buttons) communicates to the mediator its
C# activity and the mediator dispatches the expected behav-
ior to the other participants.
The Mediator pattern ensures that components are loosely import java.awt.Font; import
coupled, such that they don't call each other explicitly, but java.awt.event.ActionEvent; import
instead do so through calls to a mediator. In the following java.awt.event.ActionListener; import
example, the Mediator registers all Components and then javax.swing.JButton; import javax.swing.JFrame; import
calls their SetState methods. javax.swing.JLabel; import javax.swing.JPanel; //Col-
public interface IComponent { void SetState(object league interface interface Command { void execute(); }
state); } public class Component1 : IComponent { //Abstract Mediator interface Mediator { void book();
public void SetState(object state) { throw new NotIm- void view(); void search(); void registerView(BtnView
plementedException(); } } public class Component2 : v); void registerSearch(BtnSearch s); void register-
IComponent { public void SetState(object state) { throw Book(BtnBook b); void registerDisplay(LblDisplay
new NotImplementedException(); } } // Mediates the d); } //Concrete mediator class ParticipantMediator
common tasks public class Mediator { public ICom- implements Mediator { BtnView btnView; BtnSearch
ponent Component1 { get; set; } public IComponent btnSearch; BtnBook btnBook; LblDisplay show; //....
Component2 { get; set; } public void ChangeS- public void registerView(BtnView v) { btnView = v; }
tate(object state) { this.Component1.SetState(state); public void registerSearch(BtnSearch s) { btnSearch =
this.Component2.SetState(state); } } s; } public void registerBook(BtnBook b) { btnBook =
b; } public void registerDisplay(LblDisplay d) { show
= d; } public void book() { btnBook.setEnabled(false);
A chat room could use the Mediator pattern, or a system btnView.setEnabled(true); btnSearch.setEnabled(true);
where many ‘clients’ each receive a message each time one show.setText(“booking...”); } public void view() {
of the other clients performs an action (for chat rooms, btnView.setEnabled(false); btnSearch.setEnabled(true);
this would be when each person sends a message). In re- btnBook.setEnabled(true); show.setText(“viewing...”);
ality using the Mediator pattern for a chat room would } public void search() { btnSearch.setEnabled(false);
only be practical when used with remoting. Using raw btnView.setEnabled(true); btnBook.setEnabled(true);
sockets wouldn’t allow for the delegate callbacks (peo- show.setText(“searching...”); } } //A concrete col-
ple subscribed to the Mediator class’ MessageReceived league class BtnView extends JButton implements
event). Command { Mediator med; BtnView(ActionListener al,
public delegate void MessageReceivedEven- Mediator m) { super(“View”); addActionListener(al);
tHandler(string message, string from); public class med = m; med.registerView(this); } public void exe-
Mediator { public event MessageReceivedEventHandler cute() { med.view(); } } //A concrete colleague class
MessageReceived; public void Send(string message, BtnSearch extends JButton implements Command
string from) { if (MessageReceived != null) { Con- { Mediator med; BtnSearch(ActionListener al, Me-
sole.WriteLine(“Sending '{0}' from {1}", message, diator m) { super(“Search”); addActionListener(al);
from); MessageReceived(message, from); } } } public med = m; med.registerSearch(this); } public void
class Person { private Mediator _mediator; public execute() { med.search(); } } //A concrete colleague
string Name { get; set; } public Person(Mediator class BtnBook extends JButton implements Command
mediator, string name) { Name = name; _mediator = { Mediator med; BtnBook(ActionListener al, Me-
mediator; _mediator.MessageReceived += new Mes- diator m) { super(“Book”); addActionListener(al);
64 CHAPTER 4. BEHAVIORAL PATTERNS

med = m; med.registerBook(this); } public void ex-
ecute() { med.book(); } } class LblDisplay extends
JLabel { Mediator med; LblDisplay(Mediator m) { su-
per(“Just start...”); med = m; med.registerDisplay(this);
setFont(new Font(“Arial”, Font.BOLD, 24)); } }
class MediatorDemo extends JFrame implements
ActionListener { Mediator med = new Participant-
Mediator(); MediatorDemo() { JPanel p = new
JPanel(); p.add(new BtnView(this, med)); p.add(new
BtnBook(this, med)); p.add(new BtnSearch(this,
med)); getContentPane().add(new LblDisplay(med),
“North”); getContentPane().add(p, “South”); set-
Size(400, 200); setVisible(true); } public void ac-
tionPerformed(ActionEvent ae) { Command comd =
(Command) ae.getSource(); comd.execute(); } public
static void main(String[] args) { new MediatorDemo(); }
}
4.6.4 See also
• Data mediation
• Design Patterns, the book which gave rise to the FromMemento(Memento memento) { this.state = me-
study of design patterns in computer science
• Design pattern (computer science), a standard solu- public static class Memento { private final String
tion to common problems in software design
4.6.5 References
[1] Gang Of Four
4.6.6 External links
• Mediator Design Pattern
• Is the use of the mediator pattern recommend? - originator.set(“State4”);
Stack Overflow
cannot, or should not, change). When using this pattern,
care should be taken if the originator may change other
objects or resources - the memento pattern operates on a
single object.
Classic examples of the memento pattern include the seed
of a pseudorandom number generator (it will always pro-
duce the same sequence thereafter when initialized with
the seed state) and the state in a finite state machine.
4.7.1 Java example
The following Java program illustrates the “undo” usage
of the memento pattern.
import java.util.List; import java.util.ArrayList; class
Originator { private String state; // The class could also
contain additional data that is not part of the // state saved
in the memento.. public void set(String state) { Sys-
tem.out.println(“Originator: Setting state to " + state);
this.state = state; } public Memento saveToMemento() {
System.out.println(“Originator: Saving to Memento.”);
return new Memento(this.state); } public void restore-
mento.getSavedState(); System.out.println(“Originator:
State after restoring from Memento: " + state); }
state; public Memento(String stateToSave) { state
= stateToSave; } private String getSavedState() {
return state; } } } class Caretaker { public static
void main(String[] args) { List<Originator.Memento>
savedStates = new ArrayList<Originator.Memento>();
Originator originator = new Originator(); origina-
tor.set(“State1”); originator.set(“State2”); saved-
States.add(originator.saveToMemento()); origi-
nator.set(“State3”); // We can request multiple
mementos, and choose which one to roll back
to. savedStates.add(originator.saveToMemento());
origina-
tor.restoreFromMemento(savedStates.get(1)); } }

The output is:

4.7 Memento pattern Originator: Setting state to State1 Originator: Setting
state to State2 Originator: Saving to Memento. Origi-
The memento pattern is a software design pattern that nator: Setting state to State3 Originator: Saving to Me-
provides the ability to restore an object to its previous mento. Originator: Setting state to State4 Originator:
state (undo via rollback). State after restoring from Memento: State3
The memento pattern is implemented with three objects: This example uses a String as the state, which is an
the originator, a caretaker and a memento. The originator immutable object in Java. In real-life scenarios the state
is some object that has an internal state. The caretaker will almost always be an object, in which case a copy of
is going to do something to the originator, but wants to the state must be done.
be able to undo the change. The caretaker first asks the
originator for a memento object. Then it does whatever It must be said that the implementation shown has a draw-
operation (or sequence of operations) it was going to do. back: it declares an internal class. It would be better if
To roll back to the state before the operations, it returns this memento strategy could apply to more than one orig-
the memento object to the originator. The memento ob- inator.
ject itself is an opaque object (one which the caretaker There are mainly three other ways to achieve Memento:
4.8. NULL OBJECT PATTERN 65

1. Serialization. methods, because methods typically cannot be invoked

on null references.
2. A class declared in the same package.
The Objective-C language takes another approach to
3. The object can also be accessed via a proxy, which this problem and does nothing when sending a message
can achieve any save/restore operation on the object. to nil; if a return value is expected, nil (for objects),
0 (for numeric values), NO (for BOOL values), or a
struct (for struct types) with all its members initialised
4.7.2 C# Example to nil/0/NO/zero-initialised struct is returned.[2]

The memento pattern allows one to capture the internal

state of an object without violating encapsulation such 4.8.2 Description
that later one can undo/revert the changes if required.
Here one can see that the memento object is actually used Instead of using a null reference to convey absence of an
to revert the changes made in the object. object (for instance, a non-existent customer), one uses
//original object public class OriginalObject { private an object which implements the expected interface, but
Memento MyMemento; public string String1 { get; whose method body is empty. The advantage of this ap-
set; } public string String2 { get; set; } public Orig- proach over a working default implementation is that a
inalObject(string str1, string str2) { this.String1 Null Object is very predictable and has no side effects: it
= str1; this.String2 = str2; this.MyMemento = does nothing.
new Memento(str1, str2); } public void Revert() { For example, a function may retrieve a list of files in a
this.String1 = this.MyMemento.string1; this.String2 = folder and perform some action on each. In the case of an
this.MyMemento.string2; } } //Memento object public empty folder, one response may be to throw an exception
class Memento { public readonly string string1; public or return a null reference rather than a list. Thus, the
readonly string string2; public Memento(string str1, code which expects a list must verify that it in fact has
string str2) { this.string1 = str1; this.string2 = str2; } } one before continuing, which can complicate the design.
By returning a null object (i.e. an empty list) instead,
there is no need to verify that the return value is in fact a
4.7.3 External links list. The calling function may simply iterate the list as
normal, effectively doing nothing. It is, however, still
• Description of Memento Pattern in Ada possible to check whether the return value is a null ob-
ject (e.g. an empty list) and react differently if desired.
• Memento UML Class Diagram with C# and .NET The null object pattern can also be used to act as a stub
code samples for testing, if a certain feature such as a database is not
• SourceMaking Tutorial available for testing.

• Memento Design Pattern using Java

4.8.3 Example

4.8 Null Object pattern Given a binary tree, with this node structure:
class node { node left node right }
“Null object” redirects here. For the concept in category One may implement a tree size procedure recursively:
theory, see Initial object.
function tree_size(node) { return 1 + tree_size(node.left)
+ tree_size(node.right) }
In object-oriented computer programming, a Null Ob-
ject is an object with no referenced value or with defined Since the child nodes may not exist, one must modify the
neutral (“null”) behavior. The Null Object design pattern procedure by adding non-existence or null checks:
describes the uses of such objects and their behavior (or function tree_size(node) { set sum = 1 if node.left exists
lack thereof). It was first published in the Pattern Lan- { sum = sum + tree_size(node.left) } if node.right exists
guages of Program Design book series.[1] { sum = sum + tree_size(node.right) } return sum }
This however makes the procedure more complicated by
mixing boundary checks with normal logic, and it be-
4.8.1 Motivation
comes harder to read. Using the null object pattern, one
In most object-oriented languages, such as Java or C#, can create a special version of the procedure but only for
references may be null. These references need to be null nodes:
checked to ensure they are not null before invoking any function tree_size(node) { return 1 + tree_size(node.left)
66 CHAPTER 4. BEHAVIORAL PATTERNS

+ tree_size(node.right) } function tree_size(null_node) { 4.8.6 In various languages

return 0 }
C++
This separates normal logic from special case handling,
and makes the code easier to understand.
A language with statically typed references to objects il-
lustrates how the null object becomes a more complicated
4.8.4 Relation to other patterns pattern:
class animal { public: virtual void make_sound() = 0; };
It can be regarded as a special case of the State pattern class dog : public animal { void make_sound() { cout <<
and the Strategy pattern. “woof!" << endl; } }; class null_animal : public animal
It is not a pattern from Design Patterns, but is men- { void make_sound() { } };
tioned in Martin Fowler’s Refactoring[3] and Joshua
Kerievsky’s[4] book on refactoring in the Insert Null Ob- Here, the idea is that there are situations where a pointer
ject refactoring. or reference to an animal object is required, but there
Chapter 17 is dedicated to the pattern in Robert Cecil is no appropriate object available. A null reference is
Martin’s Agile Software Development: Principles, Patterns impossible in standard-conforming C++. A null an-
and Practices[5] imal * pointer is possible, and could be useful as a
place-holder, but may not be used for direct dispatch:
a->make_sound() is undefined behavior if a is a null
4.8.5 Alternatives pointer.
The null object pattern solves this problem by providing a
From C# 6.0 it is possible to use the "?.” operator (aka special null_animal class which can be instantiated bound
null-conditional operator) as shown below: to an animal pointer or reference.
// compile as Console Application, requires C# 6.0 or The special null class must be created for each class hier-
higher using System; namespace ConsoleApplication2 archy that is to have a null object, since a null_animal is
{ class Program { static void Main(string[] args) { of no use when what is needed is a null object with regard
string str = “test"; Console.WriteLine(str?.Length); to some widget base class that is not related to the animal
Console.ReadKey(); } } } // The output will be: // 4 hierarchy.
Note, that NOT having a null class at all is an impor-
tant feature, in contrast to languages where “anything is
Extension methods and Null coalescing a reference” (e.g. Java and C#). In C++, the design of
a function or method may explicitly state whether null is
In some Microsoft .NET languages, Extension methods allowed or not.
can be used to perform what is called 'null coalescing'. // function which requires an animal instance, // and will
This is because extension methods can be called on null not accept null void do_something( const animal& Inst )
values as if it concerns an 'instance method invocation' { // Inst may never be null here } // function which may
while in fact extension methods are static. Extension accept an animal instance or null void do_something(
methods can be made to check for null values, thereby const animal* pInst ) { // pInst may be null }
freeing code that uses them from ever having to do so.
Note that the example below uses the C# Null coalesc-
ing operator to guarantee error free invocation, where it
could also have used a more mundane if...then...else. C#
// compile as Console Application, requires C# 3.0
or higher using System; using System.Linq; names- C# is a language in which the Null Object pattern can be
pace MyExtensionWithExample { public static class properly implemented. This example shows animal ob-
StringExtensions { public static int SafeGetLength(this jects that display sounds and a NullAnimal instance used
string valueOrNull) { return (valueOrNull ?? in place of the C# null keyword. The Null Object pro-
string.Empty).Length; } } public static class Pro- vides consistent behaviour and prevents a runtime Null
gram { // define some strings static readonly string[] Reference Exception that would occur if the C# null key-
strings = new [] { “Mr X.”, “Katrien Duck”, null, “Q” word were used instead.
}; // write the total length of all the strings in the array /* Null Object Pattern implementation: */ using System;
public static void Main(string[] args) { var query = from // Animal interface is the key to compatibility for
text in strings select text.SafeGetLength(); // no need to Animal implementations below. interface IAnimal {
do any checks here Console.WriteLine(query.Sum()); } void MakeSound(); } // Animal is the base case. abstract
} } // The output will be: // 18 class Animal : IAnimal { // A shared instance that
can be used for comparisons public static readonly
4.8. NULL OBJECT PATTERN 67

IAnimal Null = new NullAnimal(); // The Null Case: tion call to list needs to reduce its argument expression to
this NullAnimal class should be used in place of C# null a value, the null object is automatically substituted.
keyword. private class NullAnimal : Animal { public
override void MakeSound() { // Purposefully provides
no behaviour. } } public abstract void MakeSound(); } CLOS
// Dog is a real animal. class Dog : IAnimal { public
void MakeSound() { Console.WriteLine(“Woof!"); } In Common Lisp, the object nil is the one and only in-
} /* ========================= * Simplistic stance of the special class null. What this means is that a
usage example in a Main entry point. */ static class Pro- method can be specialized to the null class, thereby im-
gram { static void Main() { IAnimal dog = new Dog(); plementing the null design pattern. Which is to say, it is
dog.MakeSound(); // outputs “Woof!" /* Instead of using essentially built into the object system:
C# null, use the Animal.Null instance. * This example ;; empty dog class (defclass dog () ()) ;; a dog object
is simplistic but conveys the idea that if the Animal.Null makes a sound by barking: woof! is printed on standard
instance is used then the program * will never experience output ;; when (make-sound x) is called, if x is an instance
a .NET System.NullReferenceException at runtime, of the dog class. (defmethod make-sound ((obj dog))
unlike if C# null were used. */ IAnimal unknown = (format t “woof!~%")) ;; allow (make-sound nil) to work
Animal.Null; //<< replaces: IAnimal unknown = null; via specialization to null class. ;; innocuous empty body:
unknown.MakeSound(); // outputs nothing, but does not nil makes no sound. (defmethod make-sound ((obj null)))
throw a runtime exception } }
The class null is a subclass of the symbol class, because nil
is a symbol. Since nil also represents the empty list, null
Smalltalk is a subclass of the list class, too. Methods parameters
specialized to symbol or list will thus take a nil argument.
Following the Smalltalk principle, everything is an object, Of course, a null specialization can still be defined which
the absence of an object is itself modeled by an object, is a more specific match for nil.
called nil. In the GNU Smalltalk for example, the class
of nil is UndefinedObject, a direct descendant of Object.
Scheme
Any operation that fails to return a sensible object for its
purpose may return nil instead, thus avoiding the special Unlike Common Lisp, and many dialects of Lisp, the
case of returning “no object”. This method has the ad- Scheme dialect does not have a nil value which works
vantage of simplicity (no need for a special case) over this way; the functions car and cdr may not be applied
the classical “null” or “no object” or “null reference” ap- to an empty list; Scheme application code therefore has
proach. Especially useful messages to be used with nil are to use the empty? or pair? predicate functions to sidestep
isNil or ifNil:, which make it practical and safe to deal this situation, even in situations where very similar Lisp
with possible references to nil in Smalltalk programs. would not need to distinguish the empty and non-empty
cases thanks to the behavior of nil.
Common Lisp
Ruby
In Lisp, functions can gracefully accept the special ob-
ject nil, which reduces the amount of special case testing In duck-typed languages like Ruby, language inheritance
in application code. For instance, although nil is an atom is not necessary to provide expected behavior.
and does not have any fields, the functions car and cdr ac-
cept nil and just return it, which is very useful and results class Dog def sound “bark” end end class
in shorter code. NilAnimal def sound(*); end end def
get_animal(animal=NilAnimal.new) animal
Since nil is the empty list in Lisp, the situation described end get_animal(Dog.new).sound => “bark”
in the introduction above doesn't exist. Code which re- get_animal.sound => nil
turns nil is returning what is in fact the empty list (and
not anything resembling a null reference to a list type), so
the caller does not need to test the value to see whether Attempts to directly monkey-patch NilClass instead of
or not it has a list. providing explicit implementations give more unexpected
side effects than benefits.
The null object pattern is also supported in multiple value
processing. If the program attempts to extract a value
from an expression which returns no values, the behavior JavaScript
is that the null object nil is substituted. Thus (list (values))
returns (nil) (a one-element list containing nil). The (val- In duck-typed languages like JavaScript, language inher-
ues) expression returns no values at all, but since the func- itance is not necessary to provide expected behavior.
68 CHAPTER 4. BEHAVIORAL PATTERNS

class Dog{ sound(){ return 'bark'; } } class NullAnimal{
sound(){ return null; } } function getAnimal(type)
{ return type === 'dog' ? new Dog() : new Nul-
lAnimal(); } ['dog', null].map((animal) => getAni-
mal(animal).sound()); // Returns ["bark”, null]
Animal = New AnimalEmpty() Public Overridable Sub
MakeSound() Console.WriteLine(“Woof!") End Sub
End Class Friend NotInheritable Class AnimalEmpty
Inherits Animal Public Overrides Sub MakeSound() '
End Sub End Class

Java 4.8.7 Criticism

public interface Animal { void makeSound(); } public This pattern should be used carefully as it can make er-
class Dog implements Animal { public void makeSound() rors/bugs appear as normal program execution.[6]
{ System.out.println(“woof!"); } } public class NullAni-
Care should be taken not to implement this pattern just to
mal implements Animal { public void makeSound() { } }
avoid null checks and make code more readable, since the
harder to read code may just move to another place and be
This code illustrates a variation of the C++ example, less standard - such as when different logic must execute
above, using the Java language. As with C++, a null class in case the object provided is indeed the Null Object. The
can be instantiated in situations where a reference to an common pattern in most languages with reference types
Animal object is required, but there is no appropriate ob- is to compare a reference to a single value referred to as
ject available. A null Animal object is possible (Animal null or nil. Also, there is additional need for testing that
myAnimal = null;) and could be useful as a place-holder, no code anywhere ever assigns null instead of the Null
but may not be used for calling a method. In this ex- Object, because in most cases and languages with static
ample, myAnimal.makeSound(); will throw a NullPoint- typing, this is not a compiler error if the Null Object is of
erException. Therefore, additional code may be neces- a reference type, although it would certainly lead to errors
sary to test for null objects. at run time in parts of the code where the pattern was used
The null object pattern solves this problem by providing to avoid null checks. On top of that, in most languages
a special NullAnimal class which can be instantiated as and assuming there can be many Null Objects (i.e. the
an object of type Animal. As with C++ and related lan- Null Object is a reference type but doesn't implement the
guages, that special null class must be created for each singleton pattern in one or another way), checking for the
class hierarchy that needs a null object, since a NullAni- Null Object instead of for the null or nil value introduces
mal is of no use when what is needed is a null object that overhead, as does the singleton pattern likely itself upon
does not implement the Animal interface. obtaining the singleton reference.

PHP 4.8.8 See also

• Nullable type
interface Animal { public function makeSound(); } class
Dog implements Animal { public function makeSound() • Option type
{ echo “Woof.."; } } class Cat implements Animal
{ public function makeSound() { echo “Meowww..";
} } class NullAnimal implements Animal { public 4.8.9 References
function makeSound() { // silence... } } $animalType
= 'elephant'; switch($animalType) { case 'dog': $animal [1] Woolf, Bobby (1998). “Null Object”. In Martin, Robert;
= new Dog(); break; case 'cat': $animal = new Cat(); Riehle, Dirk; Buschmann, Frank. Pattern Languages of
break; default: $animal = new NullAnimal(); break; } Program Design 3. Addison-Wesley.
$animal->makeSound(); // ..the null animal makes no [2] “Working with Objects (Working with nil)". iOS Devel-
sound oper Library. Apple, Inc. 2012-12-13. Retrieved 2014-
05-19.

[3] Fowler, Martin (1999). Refactoring. Improving the Design

Visual Basic .NET of Existing Code. Addison-Wesley. ISBN 0-201-48567-2.

[4] Kerievsky, Joshua (2004). Refactoring To Patterns.

The following NullObject pattern implementation
demonstrates the concrete class providing its corre-
sponding NullObject in a static field Empty. This
approach is frequently used in the .NET Framework
(String.Empty, EventArgs.Empty, Guid.Empty, etc.).
Addison-Wesley. ISBN 0-321-21335-1.
[5] Martin, Robert (2002). Agile Software Development:
Principles, Patterns and Practices. Pearson Education.
ISBN 0-13-597444-5.

Public Class Animal Public Shared ReadOnly Empty As [6] Fowler, Martin (1999). Refactoring pp. 216
4.9. OBSERVER PATTERN
4.8.10 External links
• Jeffrey Walkers’ account of the Null Object Pattern
• Martin Fowlers’ description of Special Case, a
slightly more general pattern
• Null Object Pattern Revisited
• Introduce Null Object refactoring
• Why NULL Is Bad by Yegor Bugayenko
• SourceMaking Tutorial
• Null Object Pattern in Swift
4.9 Observer pattern
The observer pattern is a software design pattern in
which an object, called the subject, maintains a list of
its dependents, called observers, and notifies them auto-
matically of any state changes, usually by calling one of
their methods.
It is mainly used to implement distributed event han-
dling systems, in “event driven” software. Most mod-
ern languages such as Java and C# have built in “event”
constructs which implement the observer pattern compo-
nents, for easy programming and short code.
The observer pattern is also a key part in the familiar
model–view–controller (MVC) architectural pattern.[1]
The observer pattern is implemented in numerous
Related patterns: Publish–subscribe pattern, mediator,
programming libraries and systems, including almost all
singleton.
GUI toolkits.
4.9.1 Strong vs. Weak reference
The observer pattern can cause memory leaks, known
as the lapsed listener problem, because in basic imple-
mentation it requires both explicit registration and ex-
plicit deregistration, as in the dispose pattern, because the
subject holds strong references to the observers, keeping
them alive. This can be prevented by the subject holding
weak references to the observers.
4.9.2 Coupling and typical pub-sub imple-
mentations
Typically, the observer pattern is implemented with the
“subject” (which is being “observed”) being part of the
object who’s state change is being observed, to be com-
municated to the observers upon occurrence. This type
of implementation is considered "tightly coupled", forc-
ing both the observers and the subject to be aware of each
other and have access to their internal parts, creating pos-
sible issues of scalability, speed, message recovery and
69
maintenance (also called event or notification loss), the
lack of flexibility in conditional dispersion and possible
hindrance to desired security measures. In some (non-
polling) implementations of the publish-subscribe pattern
(also called the pub-sub pattern), this is solved by creat-
ing a dedicated “message queue” server and at times an
extra “message handler” object, as added stages between
the observer and the observed object who’s state is be-
ing checked, thus “decoupling” the software components.
In these cases, the message queue server is accessed by
the observers with the observer pattern, “subscribing to
certain messages” knowing only about the expected mes-
sage (or even that not), but knowing nothing about the
message sender itself, and the sender may know noth-
ing about the receivers. Other implementations of the
publish-subscribe pattern, which achieve a similar effect
of notification and communication to interested parties,
do not use the observer pattern altogether.[2][3]
Still, in early implementations of multi-window operat-
ing systems like OS2 and Windows, the terms “publish-
subscribe pattern” and “event driven software develop-
ment” were used as a synonym for the observer pattern.[4]
The observer pattern, as described in the GOF book, is a
very basic concept and does not deal with observance re-
moval or with any conditional or complex logic handling
to be done by the observed “subject” before or after no-
tifying the observers. The pattern also does not deal with
recording the “events”, the asynchronous passing of the
notifications or guaranteeing their being received. These
concerns are typically dealt with in message queueing sys-
tems of which the observer pattern is only a small part.
4.9.3 Structure
UML class diagram of Observer pattern
4.9.4 Example
Below is an example written in Java that takes keyboard
input and treats each input line as an event. The exam-
ple is built upon the library classes java.util.Observer and
java.util.Observable. When a string is supplied from Sys-
tem.in, the method notifyObservers is then called, in or-
der to notify all observers of the event’s occurrence, in
70 CHAPTER 4. BEHAVIORAL PATTERNS

the form of an invocation of their 'update' methods. 4.10 Publish/subscribe

import java.util.Observable; import java.util.Scanner;
class EventSource extends Observable implements
For the Macintosh feature introduced with System 7,
Runnable { public void run() { while (true) { String re-
see Publish and Subscribe (Mac OS). For the practice
sponse = new Scanner(System.in).next(); setChanged();
of paying before a work is complete, see Subscription
notifyObservers(response); } } }
business model.
import java.util.Observable; import java.util.Observer;
“PubSub” redirects here. For the defunct search website,
public class MyApp { public static void main(String[]
see PubSub (website).
args) { System.out.println(“Enter Text: ");
EventSource eventSource = new EventSource();
eventSource.addObserver(new Observer() { public In software architecture, publish–subscribe is a
void update(Observable obj, Object arg) { Sys- messaging pattern where senders of messages, called
tem.out.println(“Received response: " + arg); } }); new publishers, do not program the messages to be sent
Thread(eventSource).start(); } } /* interface Observer{ directly to specific receivers, called subscribers, but
public void update(Observable obj, Object arg); }*/ instead characterize published messages into classes
without knowledge of which subscribers, if any, there
may be. Similarly, subscribers express interest in one
A similar example in Python:
or more classes and only receive messages that are of
class Observable: def __init__(self): self.__observers interest, without knowledge of which publishers, if any,
= [] def register_observer(self, observer): there are.
self.__observers.append(observer) def no-
Publish–subscribe is a sibling of the message queue
tify_observers(self, *args, **kwargs): for observer in
paradigm, and is typically one part of a larger message-
self.__observers: observer.notify(self, *args, **kwargs)
oriented middleware system. Most messaging systems
class Observer: def __init__(self, observable): observ-
support both the pub/sub and message queue models in
able.register_observer(self) def notify(self, observable,
their API, e.g. Java Message Service (JMS).
*args, **kwargs): print('Got', args, kwargs, 'From',
observable) subject = Observable() observer = Ob- This pattern provides greater network scalability and a
server(subject) subject.notify_observers('test') more dynamic network topology, with a resulting de-
creased flexibility to modify the publisher and the struc-
ture of the published data.

4.9.5 See also

• Implicit invocation

• Client–server model 4.10.1 Message filtering

In the publish–subscribe model, subscribers typically re-

4.9.6 References ceive only a subset of the total messages published. The
process of selecting messages for reception and process-
[1] “Model-View-Controller”. MSDN. Retrieved 2015-04- ing is called filtering. There are two common forms of
21. filtering: topic-based and content-based.
In a topic-based system, messages are published to “top-
[2] Comparison between different observer pattern imple-
ics” or named logical channels. Subscribers in a topic-
mentations Moshe Bindler, 2015 (Github)
based system will receive all messages published to the
topics to which they subscribe, and all subscribers to a
[3] Differences between pub/sub and observer pattern The
Observer Pattern by Adi Osmani (Safari books online)
topic will receive the same messages. The publisher is
responsible for defining the classes of messages to which
[4] The Windows Programming Experience Charles Petzold,
subscribers can subscribe.
Nov 10, 1992, PC Magazine (Google Books) In a content-based system, messages are only delivered
to a subscriber if the attributes or content of those mes-
sages match constraints defined by the subscriber. The
4.9.7 External links subscriber is responsible for classifying the messages.
Some systems support a hybrid of the two; publish-
• Observer implementations in various languages at ers post messages to a topic while subscribers register
Wikibooks content-based subscriptions to one or more topics.
4.10. PUBLISH/SUBSCRIBE
4.10.2 Topologies
In many pub/sub systems, publishers post messages to
an intermediary message broker or event bus, and sub-
scribers register subscriptions with that broker, letting Scalability
the broker perform the filtering. The broker normally
performs a store and forward function to route messages
from publishers to subscribers. In addition, the broker
may prioritize messages in a queue before routing.
Subscribers may register for specific messages at build
time, initialization time or runtime. In GUI systems, sub-
scribers can be coded to handle user commands (e.g.,
click of a button), which corresponds to build time reg-
istration. Some frameworks and software products use
XML configuration files to register subscribers. These
configuration files are read at initialization time. The most
sophisticated alternative is when subscribers can be added
or removed at runtime. This latter approach is used, for
example, in database triggers, mailing lists, and RSS.
The Data Distribution Service (DDS) middleware does
not use a broker in the middle. Instead, each publisher
and subscriber in the pub/sub system shares meta-data
about each other via IP multicast. The publisher and the
subscribers cache this information locally and route mes-
sages based on the discovery of each other in the shared
cognizance.
4.10.3 History
One of the earliest publicly described pub/sub systems
was the “news” subsystem of the Isis Toolkit, described at
the 1987 Association for Computing Machinery (ACM)
Symposium on Operating Systems Principles conference
(SOSP '87), in a paper “Exploiting Virtual Synchrony in
Distributed Systems. 123–138”.[1]
4.10.4 Advantages
Loose coupling
Publishers are loosely coupled to subscribers,
and need not even know of their existence.
With the topic being the focus, publishers and
subscribers are allowed to remain ignorant of
system topology. Each can continue to operate
normally regardless of the other. In the tradi-
tional tightly coupled client–server paradigm,
the client cannot post messages to the server
while the server process is not running, nor can
the server receive messages unless the client
is running. Many pub/sub systems decouple
not only the locations of the publishers and
subscribers, but also decouple them tempo-
rally. A common strategy used by middleware
analysts with such pub/sub systems is to take
down a publisher to allow the subscriber to
71
work through the backlog (a form of bandwidth
throttling).
Pub/sub provides the opportunity for bet-
ter scalability than traditional client–server,
through parallel operation, message caching,
tree-based or network-based routing, etc.
However, in certain types of tightly coupled,
high-volume enterprise environments, as sys-
tems scale up to become data centers with
thousands of servers sharing the pub/sub in-
frastructure, current vendor systems often lose
this benefit; scalability for pub/sub products
under high load in these contexts is a research
challenge.
Outside of the enterprise environment, on the
other hand, the pub/sub paradigm has proven
its scalability to volumes far beyond those of
a single data centre, providing Internet-wide
distributed messaging through web syndication
protocols such as RSS and Atom (standard).
These syndication protocols accept higher la-
tency and lack of delivery guarantees in ex-
change for the ability for even a low-end web
server to syndicate messages to (potentially)
millions of separate subscriber nodes.
4.10.5 Disadvantages
The most serious problems with pub/sub systems are a
side-effect of their main advantage: the decoupling of
publisher from subscriber.
Inflexible Semantic coupling
The structure of the data published must be well defined,
and quickly becomes rather inflexible. In order to mod-
ify the published data structure, it would be necessary to
know about all the Subscribers, and either modify them
also, or maintain compatibility with older versions. This
makes refactoring of Publisher code much more difficult.
Since requirements change over time, the inflexibility of
the data structure becomes a burden on the programmer.
However, this is a common issue with any client/server
architecture and is best served by versioning content pay-
loads or topics and/or changing URL end points for back-
ward compatibility.
In more academic terms:
[It is true that] Pub/sub systems have loose coupling
within space, time and synchronization, providing a scal-
able infrastructure for information exchange and dis-
tributed workflows. However, pub/sub are tightly cou-
pled, via event subscriptions and patterns, to the seman-
72
tics of the underlying event schema and values. The high
degree of semantic heterogeneity of events in large and
open deployments such as smart cities and the sensor
web makes it difficult to develop and maintain pub/sub
systems. In order to address semantic coupling within
pub/sub systems the use of approximate semantic match-
ing of events is an active area of research.[2]
Message Delivery Issues
A pub/sub system must be designed carefully to be able
to provide stronger system properties that a particular ap-
plication might require, such as assured delivery.
• The broker in a pub/sub system may be designed to
deliver messages for a specified time, but then stop
attempting delivery, whether or not it has received
confirmation of successful receipt of the message by
all subscribers. A pub/sub system designed in this
way cannot guarantee delivery of messages to any
applications that might require such assured deliv-
ery. Tighter coupling of the designs of such a pub-
lisher and subscriber pair must be enforced outside
of the pub/sub architecture to accomplish such as-
sured delivery (e.g. by requiring the subscriber to
publish receipt messages).
• A publisher in a pub/sub system may assume that
a subscriber is listening, when in fact it is not. A
factory may utilize a pub/sub system where equip-
ment can publish problems or failures to a subscriber
that displays and logs those problems. If the logger
fails (crashes), equipment problem publishers won't
necessarily receive notice of the logger failure, and
error messages will not be displayed or recorded by
any equipment on the pub/sub system. It should be
noted that this is also a design challenge for alterna-
tive messaging architectures, such as a client/server
system. In a client/server system, when an error
logger fails, the system will receive an indication
4.10.6 See also
of the error logger (server) failure. However, the
client/server system will have to deal with that fail-
ure by having redundant logging servers online, or
by dynamically spawning fallback logging servers.
This adds complexity to the client and server de-
signs, as well as to the client/server architecture as
a whole. However, in a pub/sub system, redundant
logging subscribers that are exact duplicates of the
existing logger can be added to the system to in-
crease logging reliability without any impact to any
other equipment on the system. In a pub/sub sys-
tem, the feature of assured error message logging
can be added incrementally, subsequent to imple-
menting the basic functionality of equipment prob-
lem message logging.
The pub/sub pattern scales well for small networks with a
small number of publisher and subscriber nodes and low
CHAPTER 4. BEHAVIORAL PATTERNS
message volume. However, as the number of nodes and
messages grows, the likelihood of instabilities increases,
limiting the maximum scalability of a pub/sub network.
Example throughput instabilities at large scales include:
• Load surges—periods when subscriber requests sat-
urate network throughput followed by periods of low
message volume (underutilized network bandwidth)
• Slowdowns—more and more applications use the
system (even if they are communicating on separate
pub/sub channels) the message volume flow to an in-
dividual subscriber will slow
• IP broadcast storms—a local area network may be
shut down entirely by saturating it with overhead
messages that choke out all normal traffic unrelated
to the pub/sub traffic
For pub/sub systems that use brokers (servers), the argu-
ment for a broker to send messages to a subscriber is in-
band, and can be subject to security problems. Brokers
might be fooled into sending notifications to the wrong
client, amplifying denial of service requests against the
client. Brokers themselves could be overloaded as they
allocate resources to track created subscriptions.
Even with systems that do not rely on brokers, a sub-
scriber might be able to receive data that it is not au-
thorized to receive. An unauthorized publisher may be
able to introduce incorrect or damaging messages into the
pub/sub system. This is especially true with systems that
broadcast or multicast their messages. Encryption (e.g.
Transport Layer Security (SSL/TLS)) can prevent unau-
thorized access, but cannot prevent damaging messages
from being introduced by authorized publishers. Archi-
tectures other than pub/sub, such as client/server systems,
are also vulnerable to authorized message senders that be-
have maliciously.
• Atom (standard), another highly scalable web-
syndication protocol
• Data Distribution Service (DDS)
• Event-driven programming
• High-level architecture
• Internet Group Management Protocol
• Message brokers
• Message queue
• Observer Pattern
• PubSubHubbub, an implementation of pub/sub
• RSS, a highly scalable web-syndication protocol
4.11. DESIGN PATTERN SERVANT 73

• Push technology 4.11.1 Description and simple example

• Usenet Servant is used for providing some behavior to a group of

classes. Instead of defining that behavior in each class - or
when we cannot factor out this behavior in the common
4.10.7 References parent class - it is defined once in the Servant.
For example: we have a few classes representing geomet-
[1] Birman, K. and Joseph, T. "Exploiting virtual synchrony
ric objects (rectangle, ellipse, and triangle). We can draw
in distributed systems" in Proceedings of the eleventh ACM
these objects on some canvas. When we need to pro-
Symposium on Operating systems principles (SOSP '87), vide a “move” method for these objects we could imple-
1987. pp. 123–138. ment this method in each class, or we can define an in-
terface they implement and then offer the “move” func-
[2] Hasan, Souleiman, Sean O’Riain, and Edward Curry.
tionality in a servant. An interface is defined to ensure
2012. “Approximate Semantic Matching of Heteroge-
that serviced classes have methods, that servant needs to
neous Events.” In 6th ACM International Conference on
Distributed Event-Based Systems (DEBS 2012), 252– provide desired behavior. If we continue in our exam-
263. Berlin, Germany: ACM. “DOI”. ple, we define an Interface “Movable” specifying that ev-
ery class implementing this interface needs to implement
method “getPosition” and “setPosition”. The first method
gets the position of an object on a canvas and second one
4.10.8 External links sets the position of an object and draws it on a canvas.
Then we define a servant class “MoveServant”, which has
• XMPP XEP-0060: Publish-Subscribe two methods “moveTo(Movable movedObject, Position
where)” and moveBy(Movable movedObject, int dx, int
• Message Broker MQTT With Publish-Subscribe dy). The Servant class can now be used to move every
Paradiam object which implements the Movable. Thus the “mov-
ing” code appears in only one class which respects the
• For an open source example which is in production “Separation of Concerns” rule.
on MSN.com and Microsoft.com, see Distributed
Publish/Subscribe Event System
4.11.2 Two ways of implementation
• Python PubSub a Python Publish-Subscribe broker
for messages *within* an application (NOT net- There are two ways to implement this design pattern.
work)

• The OMG DDS portal

• libpubsub-cpp a topic based Publish/Subscribe

framework implemented in C++

• Publish Subscribe example in C++

• Synapse is a C++ framework that implements a

Publish-subscribe pattern

• Programmer Question-Answer topics tagged with

“publish-subscribe”
Figure 1: User uses servant to achieve some functionality and
passes the serviced objects as parameters.

4.11 Design pattern Servant

In software engineering, the servant pattern defines
an object used to offer some functionality to a group
of classes without defining that functionality in each of
them. A Servant is a class whose instance (or even just
class) provides methods that take care of a desired ser-
vice, while objects for which (or with whom) the servant
does something, are taken as parameters.
1. User knows the servant (in which case he doesn’t
need to know the serviced classes) and sends mes-
sages with his requests to the servant instances, pass-
ing the serviced objects as parameters.
2. The serviced classes (geometric objects from our
example) don’t know about servant, but they imple-
ment the “IServiced” interface. The user class just
74 CHAPTER 4. BEHAVIORAL PATTERNS

calls the method of servant and passes serviced ob- // Servant class, offering its functionality to classes imple-
jects as parameters. This situation is shown on figure menting // Movable Interface public class MoveServant
1. { // Method, which will move Movable implementing
class to position where public void moveTo(Movable
serviced, Position where) { // Do some other stuff to
ensure it moves smoothly and nicely, this is // the place
to offer the functionality serviced.setPosition(where); }
// Method, which will move Movable implementing class
by dx and dy public void moveBy(Movable serviced, int
dx, int dy) { // this is the place to offer the functionality
dx += serviced.getPosition().xPosition; dy += ser-
viced.getPosition().yPosition; serviced.setPosition(new
Position(dx, dy)); } } // Interface specifying what
Figure 2: User requests operations from serviced instances, serviced classes needs to implement, to be // serviced by
which then asks servant to do it for them. servant. public interface Movable { public void setPosi-
tion(Position p); public Position getPosition(); } // One
of geometric classes public class Triangle implements
1. Serviced instances know the servant and the user Movable { // Position of the geometric object on some
sends them messages with his requests (in which canvas private Position p; // Method, which sets position
case she doesn’t have to know the servant). The ser- of geometric object public void setPosition(Position
viced instances then send messages to the instances p) { this.p = p; } // Method, which returns position of
of servant, asking for service. geometric object public Position getPosition() { return
this.p; } } // One of geometric classes public class Ellipse
2. On figure 2 is shown opposite situation, where user implements Movable { // Position of the geometric
don’t know about servant class and calls directly ser- object on some canvas private Position p; // Method,
viced classes. Serviced classes then asks servant which sets position of geometric object public void
themselves to achieve desired functionality. setPosition(Position p) { this.p = p; } // Method, which
returns position of geometric object public Position
getPosition() { return this.p; } } // One of geometric
4.11.3 How to implement Servant classes public class Rectangle implements Movable { //
Position of the geometric object on some canvas private
1. Analyze what behavior servant should take care of. Position p; // Method, which sets position of geometric
State what methods servant will define and what object public void setPosition(Position p) { this.p = p; }
these methods will need from serviced parameter. // Method, which returns position of geometric object
By other words, what serviced instance must pro- public Position getPosition() { return this.p; } } // Just
vide, so that servants methods can achieve their a very simple container class for position. public class
goals. Position { public int xPosition; public int yPosition;
public Position(int dx, int dy) { xPosition = dx; yPosition
2. Analyze what abilities serviced classes must have, so
= dy; } }
they can be properly serviced.

3. We define an interface, which will enforce imple-

mentation of declared methods.
4.11.5 Similar design pattern: Command
4. Define an interface specifying requested behavior of
serviced objects. If some instance wants to be served Design patterns Command and Servant are very similar
by servant, it must implement this interface. and implementations of them are often virtually the same.
The difference between them is the approach to the prob-
5. Define (or acquire somehow) specified servant (his lem.
class).

6. Implement defined interface with serviced classes.
4.11.4 Example
This simple example shows the situation described above.
This example is only illustrative and will not offer any
actual drawing of geometric objects, nor specification of
what they look like.
• For the Servant pattern we have some objects to
which we want to offer some functionality. We cre-
ate a class whose instances offer that functionality
and which defines an interface that serviced objects
must implement. Serviced instances are then passed
as parameters to the servant.
• For the Command pattern we have some objects
that we want to modify with some functionality. So,
4.12. SPECIFICATION PATTERN 75

we define an interface which commands which de- Composite Specification class has one function called Is-
sired functionality must be implemented. Instances SatisfiedBy that returns a boolean value. After instanti-
of those commands are then passed to original ob- ation, the specification is “chained” with other specifica-
jects as parameters of their methods. tions, making new specifications easily maintainable, yet
highly customizable business logic. Furthermore, upon
instantiation the business logic may, through method in-
Even though design patterns Command and Servant are
vocation or inversion of control, have its state altered in
similar it doesn’t mean it’s always like that. There are
order to become a delegate of other classes such as a per-
a number of situations where use of design pattern Com-
sistence repository.
mand doesn’t relate to the design pattern Servant. In these
situations we usually need to pass to called methods just
a reference to another method, which it will need in ac-
complishing its goal. Since we can’t pass references to 4.12.1 Code examples
methods in many languages, we have to pass an object
implementing an interface which declares the signature C#
of passed method.
public interface ISpecification { bool IsSatisfiedBy(object
candidate); ISpecification And(ISpecification other);
4.11.6 See also ISpecification AndNot(ISpecification other); IS-
pecification Or(ISpecification other); ISpecification
• Command pattern OrNot(ISpecification other); ISpecification Not(); }
public abstract class CompositeSpecification : ISpec-
ification { public abstract bool IsSatisfiedBy(object
4.11.7 Resources candidate); public ISpecification And(ISpecification
other) { return new AndSpecification(this, other); }
Pecinovský, Rudolf; Jarmila Pavlíčková; Luboš Pavlíček public ISpecification AndNot(ISpecification other) {
(June 2006). Let’s Modify the Objects First Approach into return new AndNotSpecification(this, other); } public
Design Patterns First (PDF). Eleventh Annual Conference ISpecification Or(ISpecification other) { return new
on Innovation and Technology in Computer Science Ed- OrSpecification(this, other); } public ISpecification
ucation, University of Bologna. OrNot(ISpecification other) { return new OrNotSpecifi-
cation(this, other); } public ISpecification Not() { return
new NotSpecification(this); } } public class AndSpecifi-
cation : CompositeSpecification { private ISpecification
4.12 Specification pattern leftCondition; private ISpecification rightCondition;
public AndSpecification(ISpecification left, ISpecifica-
tion right) { leftCondition = left; rightCondition = right;
} public override bool IsSatisfiedBy(object candidate)
{ return leftCondition.IsSatisfiedBy(candidate) &&
rightCondition.IsSatisfiedBy(candidate); } } public
class AndNotSpecification : CompositeSpecifica-
tion { private ISpecification leftCondition; private
ISpecification rightCondition; public AndNotSpec-
ification(ISpecification left, ISpecification right) {
leftCondition = left; rightCondition = right; } public
override bool IsSatisfiedBy(object candidate) { return
leftCondition.IsSatisfiedBy(candidate) && rightCondi-
tion.IsSatisfiedBy(candidate) != true; } } public class
OrSpecification : CompositeSpecification { private
Specification Pattern in UML
ISpecification leftCondition; private ISpecification right-
Condition; public OrSpecification(ISpecification left, IS-
In computer programming, the specification pattern is a pecification right) { leftCondition = left; rightCondition
particular software design pattern, whereby business rules = right; } public override bool IsSatisfiedBy(object can-
can be recombined by chaining the business rules together didate) { return leftCondition.IsSatisfiedBy(candidate)
using boolean logic. The pattern is frequently used in the || rightCondition.IsSatisfiedBy(candidate); } } public
context of domain-driven design. class OrNotSpecification : CompositeSpecifica-
A specification pattern outlines a business rule that is tion { private ISpecification leftCondition; private
combinable with other business rules. In this pattern, a ISpecification rightCondition; public OrNotSpec-
unit of business logic inherits its functionality from the ification(ISpecification left, ISpecification right) {
abstract aggregate Composite Specification class. The leftCondition = left; rightCondition = right; } public
76 CHAPTER 4. BEHAVIORAL PATTERNS

override bool IsSatisfiedBy(object candidate) { return right.IsSatisfiedBy(candidate); } } public class

leftCondition.IsSatisfiedBy(candidate) || rightCon- OrNotSpecification<T> : CompositeSpecifica-
dition.IsSatisfiedBy(candidate) != true; } } public tion<T> { private readonly ISpecification<T> left;
class NotSpecification : CompositeSpecification { private readonly ISpecification<T> right; public
private ISpecification Wrapped; public NotSpeci- OrNotSpecification(ISpecification<T> left, IS-
fication(ISpecification x) { Wrapped = x; } public pecification<T> right) { this.left = left; this.right
override bool IsSatisfiedBy(object candidate) { return = right; } public override bool IsSatisfiedBy(T
!Wrapped.IsSatisfiedBy(candidate); } } candidate) { return left.IsSatisfiedBy(candidate) ||
right.IsSatisfiedBy(candidate) != true; } } public class
NotSpecification<T> : CompositeSpecification<T>
{ private readonly ISpecification<T> other; public
C# 3.0, simplified with generics and extension meth-
NotSpecification(ISpecification<T> other) { this.other =
ods
other; } public override bool IsSatisfiedBy(T candidate)
{ return !other.IsSatisfiedBy(candidate); } }
public interface ISpecification<T> { bool IsSatisfiedBy(T
entity); ISpecification<T> And(ISpecification<T>
other); ISpecification<T> AndNot(ISpecification<T>
other); ISpecification<T> Or(ISpecification<T> other); 4.12.2 Example of use
ISpecification<T> OrNot(ISpecification<T> other);
ISpecification<T> Not(); } public abstract class Lin- In the following example, we are retrieving invoices and
qSpecification<T> : CompositeSpecification<T> { sending them to a collection agency if
public abstract Expression<Func<T, bool>> AsExpres-
sion(); public override bool IsSatisfiedBy(T entity) { 1. they are overdue,
Func<T, bool> predicate = AsExpression().Compile();
return predicate(entity); } } public abstract class 2. notices have been sent, and
CompositeSpecification<T> : ISpecification<T> { 3. they are not already with the collection agency.
public abstract bool IsSatisfiedBy(T entity); public
ISpecification<T> And(ISpecification<T> other) { This example is meant to show the end result of how the
return new AndSpecification<T>(this, other); } public logic is 'chained' together.
ISpecification<T> AndNot(ISpecification<T> other)
This usage example assumes a previously defined Over-
{ return new AndNotSpecification<T>(this, other); }
dueSpecification class that is satisfied when an invoice’s
public ISpecification<T> Or(ISpecification<T> other)
due date is 30 days or older, a NoticeSentSpecification
{ return new OrSpecification<T>(this, other); } public
class that is satisfied when three notices have been sent to
ISpecification<T> OrNot(ISpecification<T> other) {
the customer, and an InCollectionSpecification class that
return new OrNotSpecification<T>(this, other); } public
is satisfied when an invoice has already been sent to the
ISpecification<T> Not() { return new NotSpecifica-
collection agency. The implementation of these classes
tion<T>(this); } } public class AndSpecification<T> :
isn't important here.
CompositeSpecification<T> { private readonly ISpec-
ification<T> left; private readonly ISpecification<T> Using these three specifications, we created a new spec-
right; public AndSpecification(ISpecification<T> left, ification called SendToCollection which will be satisfied
ISpecification<T> right) { this.left = left; this.right when an invoice is overdue, when notices have been sent
= right; } public override bool IsSatisfiedBy(T to the customer, and are not already with the collection
candidate) { return left.IsSatisfiedBy(candidate) agency.
&& right.IsSatisfiedBy(candidate); } } public class var OverDue = new OverDueSpecification(); var Notice-
AndNotSpecification<T> : CompositeSpecifica- Sent = new NoticeSentSpecification(); var InCollection
tion<T> { private readonly ISpecification<T> left; = new InCollectionSpecification(); // example of spec-
private readonly ISpecification<T> right; public ification pattern logic chaining var SendToCollection
AndNotSpecification(ISpecification<T> left, ISpec- = OverDue.And(NoticeSent).And(InCollection.Not());
ification<T> right) { this.left = left; this.right = var InvoiceCollection = Service.GetInvoices(); fore-
right; } public override bool IsSatisfiedBy(T can- ach (var currentInvoice in InvoiceCollection) { if
didate) { return left.IsSatisfiedBy(candidate) && (SendToCollection.IsSatisfiedBy(currentInvoice)) {
right.IsSatisfiedBy(candidate) != true; } } public currentInvoice.SendToCollection(); } }
class OrSpecification<T> : CompositeSpecifica-
tion<T> { private readonly ISpecification<T> left;
private readonly ISpecification<T> right; public
OrSpecification(ISpecification<T> left, ISpeci- 4.12.3 Criticisms
fication<T> right) { this.left = left; this.right =
right; } public override bool IsSatisfiedBy(T can- The Specification Pattern could be considered a software
didate) { return left.IsSatisfiedBy(candidate) || Anti-Pattern:
4.13. STATE PATTERN 77

• Cargo Cult Programming - There lacks a well- • The Specification Pattern in Swift by Simon
defined purpose for this pattern, and there’s no guide Strandgaard
when to implement it or not. Also, see Law of the
instrument. • specification pattern in flash actionscript 3 by Rolf
Vreijdenberger
• Inner-platform effect - And() function which di-
rectly replicate && in C#. Also, Not() and poten-
tially more. Also, see Reinventing the square wheel. 4.13 State pattern
• Spaghetti/Lasagna Code - Separate classes for each
part of the specification fragments what could be a The state pattern is a behavioral software design pat-
cohesive object. In the example above, OverDue is tern that implements a state machine in an object-oriented
an extra layer between the Logic for SendToCollec- way. With the state pattern, a state machine is imple-
tion and the OverDueSpecification implementation. mented by implementing each individual state as a de-
rived class of the state pattern interface, and implement-
Most natural programming languages can accommodate ing state transitions by invoking methods defined by the
domain-driven design with the core Object Oriented con- pattern’s superclass.
cepts. The state pattern can be interpreted as a strategy pattern
Alternative example, without the Specification Pattern: which is able to switch the current strategy through invo-
cations of methods defined in the pattern’s interface.
var InvoiceCollection = Service.GetInvoices(); fore-
ach (Invoice invoice in InvoiceCollection) { in- This pattern is used in computer programming to encap-
voice.SendToCollectionIfNecessary(); } // Invoice sulate varying behavior for the same object based on its
methods: public void SendToCollectionIfNecessary() { internal state. This can be a cleaner way for an object to
if (ShouldSendToCollection()) { SendToCollection(); change its behavior at runtime without [1]:395
resorting to large
} } private bool ShouldSendToCollection() { return monolithic conditional statements and thus improve
[2]
currentInvoice.OverDue && currentInvoice.NoticeSent maintainability.
&& !currentInvoice.InCollection; }
4.13.1 Structure
This alternative uses foundation concepts of Get-Only
Properties, Condition-Logic, and Functions. The key al- Context State
ternative here is Get-Only Properties, which are well-
+request() +handle()
named to maintain the Domain-Driven language, and en-
able the continued use of the natural && operator, in-
stead of the Specification Pattern’s And() function. Fur- state.handle() ConcreteStateA ConcreteStateB
thermore, the creation of a well-named function Send-
+handle() +handle()
ToCollectionIfNecessary is potentially more useful and
descriptive, than the previous example (which could also
State in UML[1][3]
be contained in such a function, except not directly on the
object apparently).

4.12.4 References
• Evans, Eric (2004). Domain Driven Design.
Addison-Wesley. p. 224.

4.12.5 External links

State in LePUS3[3][4]
• Specifications by Eric Evans and Martin Fowler
• The Specification Pattern: A Primer by Matt
Berther 4.13.2 Example
• The Specification Pattern: A Four Part Introduction Java
using VB.Net by Richard Dalton
• The Specification Pattern in PHP by Moshe Brevda The state interface and two implementations. The state’s
method has a reference to the context object and is able
• Happyr Doctrine Specification in PHP by Happyr to change its state.
78 CHAPTER 4. BEHAVIORAL PATTERNS

interface Statelike { void writeName(StateContext chine”. www.codeproject.com. CodeProject. Retrieved 5

context, String name); } class StateLowerCase im- May 2015.
plements Statelike { @Override public void write-
[3] State pattern in UML and in LePUS3
Name(final StateContext context, final String name)
{ System.out.println(name.toLowerCase()); con- [4] legend
text.setState(new StateMultipleUpperCase()); } }
class StateMultipleUpperCase implements State-
like { /** Counter local to this state */ private int 4.13.5 External links
count = 0; @Override public void writeName(final
StateContext context, final String name) { Sys- • State Design Pattern
tem.out.println(name.toUpperCase()); /* Change
state after StateMultipleUpperCase’s writeName() gets
invoked twice */ if(++count > 1) { context.setState(new 4.14 Strategy pattern
StateLowerCase()); } } }
In computer programming, the strategy pattern (also
The context class has a state variable that it instantiates known as the policy pattern) is a behavioural software
in an initial state, in this case StateLowerCase. In its design pattern that enables an algorithm's behavior to be
method, it uses the corresponding methods of the state selected at runtime. The strategy pattern
object.
class StateContext { private Statelike myState; State- • defines a family of algorithms,
Context() { setState(new StateLowerCase()); } /** *
Setter method for the state. * Normally only called by • encapsulates each algorithm, and
classes implementing the State interface. * @param
• makes the algorithms interchangeable within that
newState the new state of this context */ void set-
family.
State(final Statelike newState) { myState = newState;
} public void writeName(final String name) { myS-
tate.writeName(this, name); } } Strategy lets the algorithm vary independently from
clients that use it.[1] Strategy is one of the patterns in-
cluded in the influential book Design Patterns by Gamma
The demonstration below shows the usage:
et al. that popularized the concept of using patterns to
public class DemoOfClientState { pub- describe software design.
lic static void main(String[] args) { fi-
For instance, a class that performs validation on incoming
nal StateContext sc = new StateContext();
data may use a strategy pattern to select a validation al-
sc.writeName(“Monday”); sc.writeName(“Tuesday”);
gorithm based on the type of data, the source of the data,
sc.writeName(“Wednesday”);
user choice, or other discriminating factors. These fac-
sc.writeName(“Thursday”); sc.writeName(“Friday”);
tors are not known for each case until run-time, and may
sc.writeName(“Saturday”); sc.writeName(“Sunday”); }
require radically different validation to be performed.
}
The validation strategies, encapsulated separately from
the validating object, may be used by other validating ob-
With the above code, the output of main() from DemoOf- jects in different areas of the system (or even different
ClientState should be: systems) without code duplication.
monday TUESDAY WEDNESDAY thursday FRIDAY The essential requirement in the programming language
SATURDAY sunday is the ability to store a reference to some code in a data
structure and retrieve it. This can be achieved by mech-
anisms such as the native function pointer, the first-class
4.13.3 See also function, classes or class instances in object-oriented pro-
gramming languages, or accessing the language imple-
• Strategy pattern mentation’s internal storage of code via reflection.

4.13.4 References 4.14.1 Structure

[1] Erich Gamma, Richard Helm, Ralph Johnson, John M.
Vlissides (1995). Design Patterns: Elements of Reusable
4.14.2 Example
Object-Oriented Software. Addison-Wesley. ISBN 0-201-
63361-2. C#

[2] Jaeger, Thomas. “The State Design Pattern vs. State Ma- The following example is in C#.
4.14. STRATEGY PATTERN
Strategy Pattern in UML
Strategy pattern in LePUS3 (legend)
1 using System; 2 3 public class Program 4 { 5 pub-
lic static void Main() 6 { 7 CalculateClient client
= new CalculateClient(new Minus()); 8 9 Con-
sole.WriteLine(“Minus: " + client.Calculate(7, 1)); 10
11 //Change the strategy 12 client.Strategy = new Plus();
13 14 Console.WriteLine(“Plus: " + client.Calculate(7,
1)); 15 } 16 } 17 18 //The interface for the strategies
19 public interface ICalculate 20 { 21 int Calculate(int
value1, int value2); 22 } 23 24 //strategies 25 //Strategy
1: Minus 26 public class Minus : ICalculate 27 { 28
public int Calculate(int value1, int value2) 29 { 30
return value1 - value2; 31 } 32 } 33 34 //Strategy 2:
Plus 35 public class Plus : ICalculate 36 { 37 public int
Calculate(int value1, int value2) 38 { 39 return value1
+ value2; 40 } 41 } 42 43 //The client 44 public class
CalculateClient 45 { 46 public ICalculate Strategy { get;
set; } 47 48 public CalculateClient(ICalculate strategy)
49 { 50 Strategy = strategy; 51 } 52 53 //Executes the
strategy 54 public int Calculate(int value1, int value2) 55
{ 56 return Strategy.Calculate(value1, value2); 57 } 58 }
Java
The following example is in Java.
import java.util.ArrayList; import java.util.List; pub-
lic class StrategyPatternWiki { public static void
main(final String[] arguments) { Customer firstCus-
tomer = new Customer(new NormalStrategy()); //
Normal billing firstCustomer.add(1.0, 1); // Start Happy
Hour firstCustomer.setStrategy(new HappyHourStrat-
egy()); firstCustomer.add(1.0, 2); // New Customer
Customer secondCustomer = new Customer(new
HappyHourStrategy()); secondCustomer.add(0.8, 1);
// The Customer pays firstCustomer.printBill(); //
79
End Happy Hour secondCustomer.setStrategy(new
NormalStrategy()); secondCustomer.add(1.3, 2); sec-
ondCustomer.add(2.5, 1); secondCustomer.printBill();
} } class Customer { private List<Double> drinks;
private BillingStrategy strategy; public Customer(final
BillingStrategy strategy) { this.drinks = new Ar-
rayList<Double>(); this.strategy = strategy; } public
void add(final double price, final int quantity) {
drinks.add(strategy.getActPrice(price*quantity)); }
// Payment of bill public void printBill() { double
sum = 0; for (Double i : drinks) { sum += i; } Sys-
tem.out.println(“Total due: " + sum); drinks.clear(); }
// Set Strategy public void setStrategy(final BillingStrat-
egy strategy) { this.strategy = strategy; } } interface
BillingStrategy { double getActPrice(final double raw-
Price); } // Normal billing strategy (unchanged price)
class NormalStrategy implements BillingStrategy {
@Override public double getActPrice(final double raw-
Price) { return rawPrice; } } // Strategy for Happy hour
(50% discount) class HappyHourStrategy implements
BillingStrategy { @Override public double getAct-
Price(final double rawPrice) { return rawPrice*0.5; } }
A much simpler example in “modern Java” (Java 8 and
later), using lambdas, may be found here.
4.14.3 Strategy and open/closed principle
Car <<interface>>
brakeBehavior : IBrakeBehavior
IBrakeBehavior
BrakeWithABS Brake
Accelerate and brake behaviors must be declared in each new car
model.
According to the strategy pattern, the behaviors of a class
should not be inherited. Instead they should be encap-
sulated using interfaces. As an example, consider a car
class. Two possible functionalities for car are brake and
accelerate.
Since accelerate and brake behaviors change frequently
between models, a common approach is to implement
these behaviors in subclasses. This approach has signifi-
cant drawbacks: accelerate and brake behaviors must be
declared in each new Car model. The work of managing
these behaviors increases greatly as the number of models
increases, and requires code to be duplicated across mod-
els. Additionally, it is not easy to determine the exact na-
ture of the behavior for each model without investigating
the code in each.
80 CHAPTER 4. BEHAVIORAL PATTERNS

The strategy pattern uses composition instead of inher- 4.14.5 References

itance. In the strategy pattern, behaviors are defined as
separate interfaces and specific classes that implement [1] Eric Freeman, Elisabeth Freeman, Kathy Sierra and Bert
these interfaces. This allows better decoupling between Bates, Head First Design Patterns, First Edition, Chapter
1, Page 24, O'Reilly Media, Inc, 2004. ISBN 978-0-596-
the behavior and the class that uses the behavior. The be-
00712-6
havior can be changed without breaking the classes that
use it, and the classes can switch between behaviors by
changing the specific implementation used without re- 4.14.6 External links
quiring any significant code changes. Behaviors can also
be changed at run-time as well as at design-time. For in- • Strategy Pattern in UML (Spanish, but english
stance, a car object’s brake behavior can be changed from model)
BrakeWithABS() to Brake() by changing the brakeBe-
havior member to: • The Strategy Pattern from the Net Objectives
brakeBehavior = new Brake(); Repository
/* Encapsulated family of Algorithms * Interface and
• Strategy Pattern for Java article
its implementations */ public interface IBrakeBehavior
{ public void brake(); } public class BrakeWithABS • Strategy Pattern for CSharp article
implements IBrakeBehavior { public void brake() {
System.out.println(“Brake with ABS applied”); } } • Strategy pattern in UML and in LePUS3 (a formal
public class Brake implements IBrakeBehavior { pub- modelling notation)
lic void brake() { System.out.println(“Simple Brake
• Refactoring: Replace Type Code with
applied”); } } /* Client that can use the algorithms
State/Strategy
above interchangeably */ public abstract class Car {
protected IBrakeBehavior brakeBehavior; public void • Implementation of the Strategy pattern in JavaScript
applyBrake() { brakeBehavior.brake(); } public void
setBrakeBehavior(final IBrakeBehavior brakeType) {
this.brakeBehavior = brakeType; } } /* Client 1 uses 4.15 Template method pattern
one algorithm (Brake) in the constructor */ public class
Sedan extends Car { public Sedan() { this.brakeBehavior
In software engineering, the template method pattern is
= new Brake(); } } /* Client 2 uses another algorithm
a behavioral design pattern that defines the program skele-
(BrakeWithABS) in the constructor */ public class SUV
ton of an algorithm in an operation, deferring some steps
extends Car { public SUV() { this.brakeBehavior =
to subclasses.[1] It lets one redefine certain steps of an al-
new BrakeWithABS(); } } /* Using the Car example */
gorithm without changing the algorithm’s structure.[2]
public class CarExample { public static void main(final
String[] arguments) { Car sedanCar = new Sedan();
sedanCar.applyBrake(); // This will invoke class “Brake” 4.15.1 Introduction
Car suvCar = new SUV(); suvCar.applyBrake(); // This
will invoke class “BrakeWithABS” // set brake behavior In the template method of this design pattern, one or more
dynamically suvCar.setBrakeBehavior( new Brake() ); algorithm steps can be overridden by subclasses to allow
suvCar.applyBrake(); // This will invoke class “Brake” } } differing behaviors while ensuring that the overarching
algorithm is still followed.[1]
This gives greater flexibility in design and is in harmony In object-oriented programming, a concrete class is cre-
with the Open/closed principle (OCP) that states that ated that provides the steps of an algorithm design. Steps
classes should be open for extension but closed for mod- that are considered invariant are implemented inside the
ification. base class. The steps that are considered to be vari-
ant, are given a default implementation or none at all.
These variant steps must be supplied by concrete derived
4.14.4 See also
subclasses.[3] Thus the general algorithm is saved in one
• Dependency injection place but the concrete steps may be changed by the sub-
classes.
• Higher-order function
The template method pattern thus manages the larger pic-
• List of object-oriented programming terms ture of task semantics, and more refined implementa-
tion details of selection and sequence of methods. This
• Mixin larger picture calls abstract and non-abstract methods for
• Policy-based design the task at hand. The non-abstract methods are com-
pletely controlled by the template method, but the ab-
• Type class stract methods, implemented in subclasses, provide the
4.15. TEMPLATE METHOD PATTERN 81

pattern’s expressive power and degree of freedom. Tem-

plate method’s abstract class may also define hook meth-
ods that may be overridden by subclasses.[2]
Some or all of the abstract methods can be specialized
in a subclass, allowing the writer of the subclass to pro-
vide particular behavior with minimal modifications to
the larger semantics. The template method (that is non-
abstract) remains unchanged in this pattern, ensuring that
the subordinate non-abstract methods and abstract meth-
ods are called in the originally intended sequence.
The template method pattern occurs frequently, at least
in its simplest case, where a method calls only one ab-
stract method when using object oriented languages. If
a software writer uses a polymorphic method at all, this
design pattern may be a rather natural consequence. This
is because a method calling an abstract or polymorphic
function is simply the reason for being of the abstract or
polymorphic method. The template method pattern may
be used to add immediate present value to the software
or with a vision to enhancements in the future.

4.15.2 Structure Template Method in LePUS3.[4]

AbstractClass • Avoid duplication in the code: the general work-

// ...
doSomething(); flow structure is implemented once in the abstract
// ...
PrimitiveOperation1(); PrimitiveOperation1() class’s algorithm, and necessary variations are im-
// ...
PrimitiveOperation1(); PrimitiveOperation2() plemented in the subclasses.[5]
// ...
TemplateMethod()
doAbsolutelyThis(); • Control at what point(s) subclassing is allowed. As
// ... doAbsolutelyThis() opposed to a simple polymorphic override, where
doSomething() the base method would be entirely rewritten allow-
ing radical change to the workflow, only the specific
details of the workflow are allowed to change.[5]

ConcreteClass Usage with code generators

PrimitiveOperation1()
The template pattern is useful working with auto-
generated code. The challenge of working with generated
PrimitiveOperation2()
code is that any refinement of the source material will lead
doSomething()
to changes in the generated code, which could overwrite
hand-written modifications. This may be solved using the
Template method: UML class diagram. Template pattern, by generating abstract code, and mak-
ing hand-written modifications to a concrete subclass or
implementation class. The abstract code may be in the
form of an abstract class in C++, or an interface in Java
4.15.3 Usage or C#. The hand-written code would go into a subclass
in C++, and an implementing class in Java or C#. When
The template method is used in frameworks, where each used with code generation, this pattern is sometimes re-
implements the invariant parts of a domain’s architecture, ferred to as the Generation Gap pattern.[6]
leaving “placeholders” for customization options. This is
an example of inversion of control. The template method
is used for the following reasons:[3] 4.15.4 See also
• Inheritance (computer science)
• Let subclasses implement varying behavior (through
method overriding).[5] • Method overriding (programming)
82 CHAPTER 4. BEHAVIORAL PATTERNS

• GRASP (object-oriented design) Client Visitor Notation: UML

• Adapter pattern
visit(a : ConcretesElementA) : void
visit(b : ConcretesElementB) : void

4.15.5 References
ConcreteVisitor1 ConcreteVisitor2
[1] Gamma, Erich; Helm, Richard; Johnson, Ralph;
Vlissides, John (1994). “Template Method”. Design Pat- visit(a : ConcretesElementA) : void visit(a : ConcretesElementA) : void
visit(b : ConcretesElementB) : void visit(b : ConcretesElementB) : void
terns. Addison-Wesley. pp. 325–330. ISBN 0-201-
63361-2.
Object structure Element

[2] Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates,

Bert (2004). Hendrickson, Mike; Loukides, Mike, eds. accept(visitor : Visitor) : void

Head First Design Patterns (paperback). 1. O'REILLY.

p. 289, 311. ISBN 978-0-596-00712-6. Retrieved 2012-
09-12. ConcreteElementA ConcreteElementB

[3] “Template Method Design Pattern”. Source Making -
teaching IT professional. Retrieved 2012-09-12. Tem-
plate Method is used prominently in frameworks.
[4] LePUS3 legend. Retrieved from http://lepus.org.uk/ref/
legend/legend.xml.
[5] Chung, Carlo (2011). Pro Objective-C Design Patterns for
iOS. Berkely, CA: Apress. p. 266. ISBN 978-1-4302-
3331-2.
[6] Vlissides, John (1998-06-22). Pattern Hatching: Design
Patterns Applied. Addison-Wesley Professional. pp. 85–
101. ISBN 978-0201432930.
4.15.6 External links
• Working with Template Classes in PHP 5
accept(visitor : Visitor) : void accept(visitor : Visitor) : void
Visitor in Unified Modeling Language (UML)
an algorithm from an object structure on which it oper-
ates. A practical result of this separation is the ability
to add new operations to extant object structures with-
out modifying the structures. It is one way to follow the
open/closed principle.
In essence, the visitor allows adding new virtual functions
to a family of classes, without modifying the classes. In-
stead, a visitor class is created that implements all of the
appropriate specializations of the virtual function. The
visitor takes the instance reference as input, and imple-
ments the goal through double dispatch.

• Template method pattern in UML and in LePUS3

(a formal modelling language)
• Template Method Design Pattern
• Template Method Example
4.16 Visitor pattern
4.16.1 Definition
The Gang of Four defines the Visitor as:
Represent an operation to be performed on
elements of an object structure. Visitor lets
you define a new operation without changing
the classes of the elements on which it oper-
ates.

The nature of the Visitor makes it an ideal pattern to plug

into public APIs thus allowing its clients to perform op-
erations on a class using a “visiting” class without having
to modify the source.[1]

4.16.2 Motivation
Consider the design of a 2D computer-aided design
(CAD) system. At its core there are several types to rep-
Visitor in LePUS3 (legend) resent basic geometric shapes like circles, lines, and arcs.
The entities are ordered into layers, and at the top of the
In object-oriented programming and software engineer- type hierarchy is the drawing, which is simply a list of
ing, the visitor design pattern is a way of separating layers, plus some added properties.
4.16. VISITOR PATTERN
A fundamental operation on this type hierarchy is sav-
ing a drawing to the system’s native file format. At first
glance it may seem acceptable to add local save methods
to all types in the hierarchy. But it is also useful to be
able to save drawings to other file formats. Adding ever
more methods for saving into many different file formats
soon clutters the relatively pure original geometric data
structure.
A naive way to solve this would be to maintain separate
functions for each file format. Such a save function would
take a drawing as input, traverse it, and encode into that
specific file format. As this is done for each added dif-
ferent format, duplication between the functions accu-
mulates. For example, saving a circle shape in a raster
format requires very similar code no matter what specific
raster form is used, and is different from other primitive
shapes. The case for other primitive shapes like lines and
polygons is similar. Thus, the code becomes a large outer
loop traversing through the objects, with a large decision
tree inside the loop querying the type of the object. An-
other problem with this approach is that it is very easy to
miss a shape in one or more savers, or a new primitive
shape is introduced, but the save routine is implemented
only for one file type and not others, leading to code ex-
tension and maintenance problems.
Instead, the Visitor pattern can be applied. It encodes a
logical operation on the whole hierarchy into one class
containing one method per type. In the CAD example,
each save function would be implemented as a separate
Visitor subclass. This would remove all duplication of
type checks and traversal steps. It would also make the
compiler complain if a shape is omitted.
Another motive is to reuse iteration code. For exam-
ple, iterating over a directory structure could be imple-
mented with a visitor pattern. This would allow creating
file searches, file backups, directory removal, etc., by im-
plementing a visitor for each function while reusing the
iteration code.
4.16.3 Details
The visitor pattern requires a programming language that
supports single dispatch. Under this condition, consider
two objects, each of some class type; one is termed the
element, and the other is visitor. An element has an ac-
cept method that can take the visitor as an argument. The
accept method calls a visit method of the visitor; the el-
ement passes itself as an argument to the visit method.
Thus:
• When the accept method is called in the program,
A classic visitor where the Print operations for each type
its implementation is chosen based on both:
are implemented in one ExpressionPrinter class as a num-
ber of overloads of the Visit method.
• The dynamic type of the element.
namespace Wikipedia { using System; using Sys-
• The static type of the visitor. tem.Text;
83
• When the associated visit method is called, its im-
plementation is chosen based on both:
• The dynamic type of the visitor.
• The static type of the element as known
from within the implementation of the
accept method, which is the same as the
dynamic type of the element. (As a
bonus, if the visitor can't handle an ar-
gument of the given element’s type, then
the compiler will catch the error.)
• Thus, the implementation of the visit method is cho-
sen based on both:
• The dynamic type of the element.
• The dynamic type of the visitor.
This effectively implements double dispatch.
For languages which object systems support
multiple dispatch, not only single dispatch,
such as Common Lisp, implementing the visi-
tor pattern in them is trivial.
In this way, one algorithm can be written to traverse a
graph of elements, and many different kinds of opera-
tions can be performed during that traversal by supplying
different kinds of visitors to interact with the elements
based on the dynamic types of both the elements and the
visitors.
Some languages (e.g., C# via the Dynamic Language
Runtime (DLR)) support multiple dispatch, which greatly
simplifies implementing the Visitor pattern (a.k.a. Dy-
namic Visitor) by allowing use of simple function over-
loading to cover all the cases being visited. A dynamic
visitor, provided it operates on public data only, conforms
to the open/closed principle (since it does not modify ex-
tant structures) and to the single responsibility principle
(since it implements the Visitor pattern in a separate com-
ponent).
4.16.4 C# example
This example shows how to print a tree representing a
numeric expression involving literals and their addition.
The same example is presented using both classic and Dy-
namic Language Runtime implementations.
Classic visitor
interface IExpressionVisitor { void
84
Visit(Literal literal); void Visit(Addition addition); }
interface IExpression { void Accept(IExpressionVisitor
visitor); } class Literal : IExpression { internal
double Value { get; set; } public Literal(double
value) { this.Value = value; } public void Ac-
cept(IExpressionVisitor visitor) { visitor.Visit(this);
} } class Addition : IExpression { internal IExpres-
sion Left { get; set; } internal IExpression Right
{ get; set; } public Addition(IExpression left, IEx-
pression right) { this.Left = left; this.Right = right;
} public void Accept(IExpressionVisitor visitor)
{ visitor.Visit(this); } } class ExpressionPrinter :
IExpressionVisitor { StringBuilder sb; public Expres-
sionPrinter(StringBuilder sb) { this.sb = sb; } public
void Visit(Literal literal) { sb.Append(literal.Value); }
public void Visit(Addition addition) { sb.Append("(");
addition.Left.Accept(this); sb.Append("+"); addi-
tion.Right.Accept(this); sb.Append(")"); } } class
Program { static void Main(string[] args) { // emulate
1+2+3 var e = new Addition( new Addition( new
Literal(1), new Literal(2) ), new Literal(3) ); var sb
= new StringBuilder(); var expressionPrinter = new
ExpressionPrinter(sb); e.Accept(expressionPrinter);
Console.WriteLine(sb); } } }
Dynamic Visitor
This example declares a separate ExpressionPrinter class
that takes care of the printing. Note that the expression
classes have to expose their members to make this possi-
ble.
namespace Wikipedia { using System; using Sys-
tem.Text; abstract class Expression { } class Literal :
Expression { public double Value { get; } public Lit-
eral(double value) { this.Value = value; } } class Addition
: Expression { public Expression Left { get; } public
Expression Right { get; } public Addition(Expression
left, Expression right) { Left = left; Right = right; } }
class ExpressionPrinter { public static void Print(Literal
literal, StringBuilder sb) { sb.Append(literal.Value); }
public static void Print(Addition addition, StringBuilder
sb) { sb.Append("("); Print((dynamic) addition.Left,
sb); sb.Append("+"); Print((dynamic) addition.Right,
sb); sb.Append(")"); } } class Program { static void Output
Main(string[] args) { // emulate 1+2+3 var e = new Addi-
tion( new Addition( new Literal(1), new Literal(2) ), new dispatching ArchivedFile dispatching SplitFile dispatch-
Literal(3) ); var sb = new StringBuilder(); Expression- ing ExtractedFile
Printer.Print((dynamic) e, sb); Console.WriteLine(sb); }
}}
4.16.5 C++ example
CHAPTER 4. BEHAVIORAL PATTERNS
Sources
#include <iostream> #include <vector> class Abstract-
Dispatcher; // Forward declare AbstractDispatcher class
File { // Parent class for the elements (ArchivedFile,
SplitFile and ExtractedFile) public: // This function
accepts an object of any class derived from Abstract-
Dispatcher and must be implemented in all derived
classes virtual void accept(AbstractDispatcher &dis-
patcher) = 0; }; // Forward declare specific elements
(files) to be dispatched class ArchivedFile; class Split-
File; class ExtractedFile; class AbstractDispatcher {
// Declares the interface for the dispatcher public: //
Declare overloads for each kind of a file to dispatch
virtual void dispatch(ArchivedFile &file) = 0; virtual
void dispatch(SplitFile &file) = 0; virtual void dis-
patch(ExtractedFile &file) = 0; }; class ArchivedFile:
public File { // Specific element class #1 public: //
Resolved at runtime, it calls the dispatcher’s over-
loaded function, corresponding to ArchivedFile. void
accept(AbstractDispatcher &dispatcher) override {
dispatcher.dispatch(*this); } }; class SplitFile: public
File { // Specific element class #2 public: // Resolved at
runtime, it calls the dispatcher’s overloaded function, cor-
responding to SplitFile. void accept(AbstractDispatcher
&dispatcher) override { dispatcher.dispatch(*this); } };
class ExtractedFile: public File { // Specific element
class #3 public: // Resolved at runtime, it calls the
dispatcher’s overloaded function, corresponding to
ExtractedFile. void accept(AbstractDispatcher &dis-
patcher) override { dispatcher.dispatch(*this); } }; class
Dispatcher: public AbstractDispatcher { // Implements
dispatching of all kind of elements (files) public: void
dispatch(ArchivedFile &file) override { std::cout <<
“dispatching ArchivedFile” << std::endl; } void dis-
patch(SplitFile &file) override { std::cout << “dispatch-
ing SplitFile” << std::endl; } void dispatch(ExtractedFile
&file) override { std::cout << “dispatching ExtractedFile”
<< std::endl; } }; int main() { ArchivedFile archived-
File; SplitFile splitFile; ExtractedFile extractedFile;
std::vector<File*> files; files.push_back(&archivedFile);
files.push_back(&splitFile);
files.push_back(&extractedFile); Dispatcher dispatcher;
for (File* file : files) { file->accept(dispatcher); } }
4.16.6 Java example
The following example is in the language Java, and shows
how the contents of a tree of nodes (in this case describing
the components of a car) can be printed. Instead of creat-
ing print methods for each node subclass (Wheel, Engine,
4.16. VISITOR PATTERN
Body, and Car), one visitor class (CarElementPrintVisi-
tor) performs the required printing action. Because dif-
ferent node subclasses require slightly different actions
to print properly, CarElementPrintVisitor dispatches ac-
tions based on the class of the argument passed to its visit
method. CarElementDoVisitor, which is analogous to a
save operation for a different file format, does likewise.
Diagram
Sources
interface CarElement { void accept(CarElementVisitor
visitor); } interface CarElementVisitor { void visit(Body
body); void visit(Car car); void visit(Engine engine);
void visit(Wheel wheel); } class Body implements
CarElement { public void accept(final CarElementVisi-
tor visitor) { visitor.visit(this); } } class Car implements
CarElement { CarElement[] elements; public Car() {
this.elements = new CarElement[] { new Wheel(“front
left”), new Wheel(“front right”), new Wheel(“back
left”), new Wheel(“back right”), new Body(), new
Engine() }; } public void accept(final CarElementVis-
itor visitor) { for (CarElement elem : elements) {
elem.accept(visitor); } visitor.visit(this); } } class Engine
implements CarElement { public void accept(final
CarElementVisitor visitor) { visitor.visit(this); } }
class Wheel implements CarElement { private String
name; public Wheel(final String name) { this.name
= name; } public String getName() { return name; }
public void accept(final CarElementVisitor visitor) { /*
* accept(CarElementVisitor) in Wheel implements *
accept(CarElementVisitor) in CarElement, so the call *
85
to accept is bound at run time. This can be considered
* the *first* dispatch. However, the decision to call
* visit(Wheel) (as opposed to visit(Engine) etc.) can
be * made during compile time since 'this’ is known
at compile * time to be a Wheel. Moreover, each
implementation of * CarElementVisitor implements the
visit(Wheel), which is * another decision that is made
at run time. This can be * considered the *second*
dispatch. */ visitor.visit(this); } } class CarElement-
DoVisitor implements CarElementVisitor { public void
visit(final Body body) { System.out.println(“Moving
my body”); } public void visit(final Car car) { Sys-
tem.out.println(“Starting my car”); } public void
visit(final Wheel wheel) { System.out.println(“Kicking
my " + wheel.getName() + " wheel”); } public void
visit(final Engine engine) { System.out.println(“Starting
my engine”); } } class CarElementPrintVisitor imple-
ments CarElementVisitor { public void visit(final Body
body) { System.out.println(“Visiting body”); } public
void visit(final Car car) { System.out.println(“Visiting
car”); } public void visit(final Engine engine) {
System.out.println(“Visiting engine”); } public void
visit(final Wheel wheel) { System.out.println(“Visiting
" + wheel.getName() + " wheel”); } } public class Visi-
torDemo { public static void main(final String[] args) {
final Car car = new Car(); car.accept(new CarElement-
PrintVisitor()); car.accept(new CarElementDoVisitor());
}}
A more flexible approach to this pattern is to create a
wrapper class implementing the interface defining the ac-
cept method. The wrapper contains a reference pointing
to the ICarElement that could be initialized through the
constructor. This approach avoids having to implement
an interface on each element. See article Java Tip 98 ar-
ticle below
Output
Visiting front left wheel Visiting front right wheel Visiting
back left wheel Visiting back right wheel Visiting body
Visiting engine Visiting car Kicking my front left wheel
Kicking my front right wheel Kicking my back left wheel
Kicking my back right wheel Moving my body Starting
my engine Starting my car
4.16.7 Common Lisp example
Sources
(defclass auto () ((elements :initarg :elements))) (defclass
auto-part () ((name :initarg :name :initform "<unnamed-
car-part>"))) (defmethod print-object ((p auto-part)
stream) (print-object (slot-value p 'name) stream))
(defclass wheel (auto-part) ()) (defclass body (auto-
part) ()) (defclass engine (auto-part) ()) (defgeneric
86
traverse (function object other-object)) (defmethod
traverse (function (a auto) other-object) (with-slots
(elements) a (dolist (e elements) (funcall function e
other-object)))) ;; do-something visitations ;; catch all
(defmethod do-something (object other-object) (format
t “don't know how ~s and ~s should interact~%" object
other-object)) ;; visitation involving wheel and integer
(defmethod do-something ((object wheel) (other-object
integer)) (format t “kicking wheel ~s ~s times~%" object
other-object)) ;; visitation involving wheel and symbol
(defmethod do-something ((object wheel) (other-object
symbol)) (format t “kicking wheel ~s symbolically
using symbol ~s~%" object other-object)) (defmethod
do-something ((object engine) (other-object integer))
(format t “starting engine ~s ~s times~%" object other-
object)) (defmethod do-something ((object engine)
(other-object symbol)) (format t “starting engine ~s
symbolically using symbol ~s~%" object other-object))
(let ((a (make-instance 'auto :elements `(,(make-instance
'wheel :name “front-left-wheel”) ,(make-instance 'wheel
:name “front-right-wheel”) ,(make-instance 'wheel
:name “rear-left-wheel”) ,(make-instance 'wheel :name
“rear-right-wheel”) ,(make-instance 'body :name “body”)
,(make-instance 'engine :name “engine”))))) ;; traverse
to print elements ;; stream *standard-output* plays the
role of other-object here (traverse #'print a *standard-
output*) (terpri) ;; print newline ;; traverse with arbitrary
context from other object (traverse #'do-something a
42) ;; traverse with arbitrary context from other object
(traverse #'do-something a 'abc))
Output
“front-left-wheel” “front-right-wheel” “rear-right-wheel”
“rear-right-wheel” “body” “engine” kicking wheel “front-
left-wheel” 42 times kicking wheel “front-right-wheel”
42 times kicking wheel “rear-right-wheel” 42 times kick-
4.16.10 References
ing wheel “rear-right-wheel” 42 times don't know how [1] Visitor pattern real-world example
“body” and 42 should interact starting engine “engine” 42
times kicking wheel “front-left-wheel” symbolically us-
ing symbol ABC kicking wheel “front-right-wheel” sym- 4.16.11 External links
bolically using symbol ABC kicking wheel “rear-right-
wheel” symbolically using symbol ABC kicking wheel
“rear-right-wheel” symbolically using symbol ABC don't
know how “body” and ABC should interact starting en-
gine “engine” symbolically using symbol ABC
Notes
The other-object parameter is superfluous in traverse.
The reason is that it is possible to use an anonymous func-
tion that calls the desired target method with a lexically
captured object:
(defmethod traverse (function (a auto)) ;; other-object
removed (with-slots (elements) a (dolist (e elements)
(funcall function e)))) ;; from here too ;; ... ;; alternative
CHAPTER 4. BEHAVIORAL PATTERNS
way to print-traverse (traverse (lambda (o) (print o
*standard-output*)) a) ;; alternative way to do-something
with ;; elements of a and integer 42 (traverse (lambda
(o) (do-something o 42)) a)
Now, the multiple dispatch occurs in the call issued from
the body of the anonymous function, and so traverse is
just a mapping function that distributes a function ap-
plication over the elements of an object. Thus all traces
of the Visitor Pattern disappear, except for the mapping
function, in which there is no evidence of two objects be-
ing involved. All knowledge of there being two objects
and a dispatch on their types is in the lambda function.
4.16.8 Related design patterns
• Command pattern – encapsulates like the visitor pat-
tern one or more functions in an object to present
them to a caller; unlike the visitor, this pattern does
not enclose a principle to traverse the object struc-
ture
• Iterator pattern – defines a traversal principle like the
visitor pattern, without making a type differentiation
within the traversed objects
4.16.9 See also
• Algebraic data type
• Double dispatch
• Multiple dispatch
• Function object
• The Visitor Family of Design Patterns at the
Wayback Machine (archived October 22, 2015).
Additional archives: April 12, 2004, March 5, 2002.
A rough chapter from The Principles, Patterns, and
Practices of Agile Software Development, Robert C.
Martin, Prentice Hall
• Visitor pattern in UML and in LePUS3 (a Design
Description Language)
• Article "Componentization: the Visitor Example
by Bertrand Meyer and Karine Arnout, Computer
(IEEE), vol. 39, no. 7, July 2006, pages 23-30.
• Article A Type-theoretic Reconstruction of the Vis-
itor Pattern
4.16. VISITOR PATTERN 87

• Article "The Essence of the Visitor Pattern" by

Jens Palsberg and C. Barry Jay. 1997 IEEE-CS
COMPSAC paper showing that accept() methods
are unnecessary when reflection is available; intro-
duces term 'Walkabout' for the technique.

• Article "A Time for Reflection" by Bruce Wallace -

subtitled “Java 1.2’s reflection capabilities eliminate
burdensome accept() methods from your Visitor pat-
tern”

• Visitor Patterns as a universal model of terminating

computation.

• Visitor Pattern using reflection(java).

• PerfectJPattern Open Source Project, Provides a

context-free and type-safe implementation of the
Visitor Pattern in Java based on Delegates.
• Visitor Design Pattern

• Article Java Tip 98: Reflect on the Visitor design

pattern
Chapter 5

Concurrency patterns

5.1 Concurrency pattern 5.1.3 External links

In software engineering, concurrency patterns are those • ScaleConf Presentation about concurrency patterns
types of design patterns that deal with the multi-threaded
programming paradigm. Examples of this class of pat-
Recordings about concurrency patterns from Software
terns include:
Engineering Radio:

• Active Object[1][2]
• Episode 12: Concurrency Pt. 1
• Balking pattern
• Barrier • Episode 19: Concurrency Pt. 2

• Double-checked locking • Episode 29: Concurrency Pt. 3

• Guarded suspension
• Leaders/followers pattern
5.2 Active object
• Monitor Object
This article is about a multi-threading technique. For the
• Reactor pattern
lockstep protocol variant, see Active objects.
• Read write lock pattern
• Scheduler pattern The active object design pattern decouples method exe-
cution from method invocation for objects that each re-
• Thread pool pattern side in their own thread of control.[1] The goal is to in-
troduce concurrency, by using asynchronous method in-
• Thread-local storage vocation and a scheduler for handling requests.[2]
The pattern consists of six elements:[3]
5.1.1 See also
• Design Patterns • A proxy, which provides an interface towards clients
with publicly accessible methods.
• Behavioral pattern
• Creational pattern • An interface which defines the method request on an
active object.
• Structural pattern
• A list of pending requests from clients.
5.1.2 References
• A scheduler, which decides which request to execute
[1] Douglas C. Schmidt, Michael Stal, Hans Rohnert, Frank next.
Buschmann “Pattern-Oriented Software Architecture,
Volume 2, Patterns for Concurrent and Networked Ob- • The implementation of the active object method.
jects”, Wiley, 2000

[2] R. Greg Lavender, Doublas C Scmidt (1995). “Active Ob- • A callback or variable for the client to receive the
ject” (PDF). Retrieved 2010-06-17. result.

88
5.3. BALKING PATTERN
5.2.1 Example
Java
[4]
An example of active object pattern in Java.
class OriginalClass { private double val = 0.0; void
doSomething() { val = 1.0; } void doSomethingElse()
{ val = 2.0; } } class BecomeActiveObject { private
double val = 0.0; private BlockingQueue<Runnable> dis-
patchQueue = new LinkedBlockingQueue<Runnable>();
public BecomeActiveObject() { new Thread (new
Runnable() { @Override public void run() { while(true)
{ try { dispatchQueue.take().run(); } catch (Interrupt-
edException e) { // okay, just terminate the dispatcher
} } } } ).start(); } // void doSomething() throws Inter-
ruptedException { dispatchQueue.put(new Runnable()
{ @Override public void run() { val = 1.0; } } ); } //
void doSomethingElse() throws InterruptedException {
dispatchQueue.put(new Runnable() { @Override public
void run() { val = 2.0; } } ); } }
Java 8 (alternative)
Another example of active object pattern in Java.
public class AnotherActiveObject { private double object cannot support its API, it should either limit the
val; // container for tasks // decides which request to API so that the offending call is not available, or so that
execute next // asyncMode=true means our worker the call can be made without limitation it should:
thread processes its local task queue in the FIFO
order // only single thread may modify internal state
private final ForkJoinPool fj = new ForkJoinPool(1,
ForkJoinPool.defaultForkJoinWorkerThreadFactory,
null, true); // implementation of active object method
public void doSomething() throws InterruptedException
{ fj.execute(() -> {val = 1.0;}); } // implementation of
active object method public void doSomethingElse()
throws InterruptedException { fj.execute(() -> {val =
2.0;}); } }
5.2.2 See also
• Concurrent object-oriented programming
• Actor model
• Futures and promises
• Live distributed object
5.2.3 References
[1] Douglas C. Schmidt; Michael Stal; Hans Rohnert; Frank
Buschmann (2000). Pattern-Oriented Software Architec-
ture, Volume 2: Patterns for Concurrent and Networked
Objects. John Wiley & Sons. ISBN 0-471-60695-2.
89
[2] Bass, L., Clements, P., Kazman, R. Software Architecture
in Practice. Addison Wesley, 2003
[3] Lavender, R. Greg; Schmidt, Douglas C. “Active Object”
(PDF). Retrieved 2007-02-02.
[4] Holub, Allen. “Java Active Objects - A Proposal”. Re-
trieved 2014-06-16.
5.2.4 External links
• Active Object implementation in C++11
5.3 Balking pattern
The balking pattern is a software design pattern that
only executes an action on an object when the object is
in a particular state. For example, if an object reads ZIP
files and a calling method invokes a get method on the ob-
ject when the ZIP file is not open, the object would “balk”
at the request. In the Java programming language, for ex-
ample, an IllegalStateException might be thrown under
these circumstances.
There are some specialists in this field who consider balk-
ing more of an anti-pattern than a design pattern. If an
• Be created in a “sane state”
• Not make itself available until it is in a sane state
• Become a facade and answer back an object that is
in a sane state
5.3.1 Usage
Objects that use this pattern are generally only in a state
that is prone to balking temporarily but for an unknown
amount of time. If objects are to remain in a state which
is prone to balking for a known, finite period of time, then
the guarded suspension pattern may be preferred.
5.3.2 Implementation
Below is a general, simple example for an implementation
of the balking pattern.[1] As demonstrated by the defini-
tion above, notice how the “synchronized” line is utilized.
If there are multiple calls to the job method, only one
will proceed while the other calls will return with noth-
ing. Another thing to note is the jobCompleted() method.
The reason it is synchronized is because the only way to
guarantee another thread will see a change to a field is to
synchronize all access to it or declare it as volatile.
90
public class Example { private boolean jobInProgress =
false; public void job() { synchronized(this) { if (jobIn-
Progress) { return; } jobInProgress = true; } // Code
to execute job goes here // ... } void jobCompleted() {
synchronized(this) { jobInProgress = false; } } }
5.3.3 See also
• Read and write lock pattern
• Guarded suspension pattern
5.3.4 References
[1] Grand, Mark (2002). Patterns in Java, Volume 1: A Cata-
log of Reusable Design Patterns Illustrated with UML, Sec-
ond Edition. Indianapolis, Ind: John Wiley & Sons.
5.4 Messaging pattern
In software architecture, a messaging pattern is a
network-oriented architectural pattern which describes
how two different parts of a message passing system con-
nect and communicate with each other.
In telecommunications, a message exchange pattern
(MEP) describes the pattern of messages required
by a communications protocol to establish or use a
communication channel. There are two major mes-
sage exchange patterns — a request–response pattern,
and a one-way pattern. For example, HTTP is a
request–response pattern protocol, and UDP is a one-way
pattern.[1]
5.4.1 SOAP
The term “Message Exchange Pattern” has a specific
meaning within the Simple Object Access protocol
(SOAP).[2][3] SOAP MEP types include:
1. In-Only: This is equivalent to one-way. A standard
one-way messaging exchange where the consumer
sends a message to the provider that provides only a
status response.
2. Robust In-Only: This pattern is for reliable one- and thus usable on Internet scale.[5]
way message exchanges. The consumer initiates
with a message to which the provider responds with
status. If the response is a status, the exchange is 5.4.3 See also
complete, but if the response is a fault, the consumer
must respond with a status.
3. In-Out: This is equivalent to request–response. A
standard two-way message exchange where the con-
sumer initiates with a message, the provider re-
CHAPTER 5. CONCURRENCY PATTERNS
sponds with a message or fault and the consumer re-
sponds with a status.
4. In-Optional-Out: A standard two-way message ex-
change where the provider’s response is optional.
5. Out-Only: The reverse of In-Only. It primarily
supports event notification. It cannot trigger a fault
message.
6. Robust Out-Only: Similar to the out-only pattern,
except it can trigger a fault message. The outbound
message initiates the transmission.
7. Out-In: The reverse of In-Out. The provider trans-
mits the request and initiates the exchange.
8. Out-Optional-In: The reverse of In-Optional-Out.
The service produces an outbound message. The in-
coming message is optional (“Optional-in”).
5.4.2 ØMQ
The ØMQ message queueing library provides so-called
sockets (a kind of generalization over the traditional IP
and Unix sockets) which require indicating a messaging
pattern to be used, and are optimized for each pattern.
The basic ØMQ patterns are:[4]
• Request–reply connects a set of clients to a set of
services. This is a remote procedure call and task
distribution pattern.
• Publish–subscribe connects a set of publishers to a
set of subscribers. This is a data distribution pattern.
• Push–pull connects nodes in a fan-out / fan-in pat-
tern that can have multiple steps, and loops. This is
a parallel task distribution and collection pattern.
• Exclusive pair connects two sockets in an exclu-
sive pair. This is a low-level pattern for specific, ad-
vanced use cases.
Each pattern defines a particular network topology.
Request-reply defines so-called “service bus”, publish-
subscribe defines “data distribution tree”, push-pull de-
fines “parallelised pipeline”. All the patterns are deliber-
ately designed in such a way as to be infinitely scalable
• Push technology
• Distributed data flow
• Enterprise Integration Patterns
5.5. DOUBLE-CHECKED LOCKING 91

5.4.4 References If one wished to use this idiom in C++11 (For instance
with Visual Studio 2013 because lack of “Magic statics”
[3]
[1] Erl, Thomas (2005). Service Oriented Architecture: Con- ) they should use acquire and release fences:[4]
cepts, Technology, and Design. Indiana: Pearson Educa-
tion. p. 171. ISBN 0-13-185858-0. std::atomic<Singleton*> Singleton::m_instance;
std::mutex Singleton::m_mutex; Singleton*
[2] http://www.w3.org/TR/soap12-part1/#soapmep SOAP Singleton::getInstance() { Singleton* tmp =
MEPs in SOAP W3C Recommendation v1.2 m_instance.load(std::memory_order_relaxed);
std::atomic_thread_fence(std::memory_order_acquire);
[3] Web Services Description Language (WSDL) Version if (tmp == nullptr) { std::lock_guard<std::mutex>
2.0: Additional MEPs
lock(m_mutex); tmp =
[4] ØMQ User Guide m_instance.load(std::memory_order_relaxed);
if (tmp == nullptr) { tmp = new Singleton;
[5] Scalability Layer Hits the Internet Stack std::atomic_thread_fence(std::memory_order_release);
m_instance.store(tmp, std::memory_order_relaxed); } }
return tmp; }
5.4.5 External links

• Messaging Patterns in Service-Oriented Architec-

ture 5.5.2 Usage in Java

• Enterprise Integration Patterns - Pattern Catalog Consider, for example, this code segment in the Java pro-
gramming language as given by [2] (as well as all other
Java code segments):
5.5 Double-checked locking // Single-threaded version class Foo { private Helper
helper; public Helper getHelper() { if (helper == null)
In software engineering, double-checked locking (also { helper = new Helper(); } return helper; } // other
known as “double-checked locking optimization”[1] ) is a functions and members... }
software design pattern used to reduce the overhead of
acquiring a lock by first testing the locking criterion (the The problem is that this does not work when using multi-
“lock hint”) without actually acquiring the lock. Only if ple threads. A lock must be obtained in case two threads
the locking criterion check indicates that locking is re- call getHelper() simultaneously. Otherwise, either they
quired does the actual locking logic proceed. may both try to create the object at the same time, or
The pattern, when implemented in some lan- one may wind up getting a reference to an incompletely
guage/hardware combinations, can be unsafe. At initialized object.
times, it can be considered an anti-pattern.[2] The lock is obtained by expensive synchronizing, as is
It is typically used to reduce locking overhead when im- shown in the following example.
plementing "lazy initialization" in a multi-threaded envi- // Correct but possibly expensive multithreaded version
ronment, especially as part of the Singleton pattern. Lazy class Foo { private Helper helper; public synchronized
initialization avoids initializing a value until the first time Helper getHelper() { if (helper == null) { helper =
it is accessed. new Helper(); } return helper; } // other functions and
members... }

5.5.1 Usage in C++11

For the singleton pattern, double-checked locking is not
needed:
If control enters the declaration concur-
rently while the variable is being initialized,
the concurrent execution shall wait for com-
pletion of the initialization.
— § 6.7 [stmt.dcl] p4
However, the first call to getHelper() will create the ob-
ject and only the few threads trying to access it during
that time need to be synchronized; after that all calls just
get a reference to the member variable. Since synchro-
nizing a method could in some extreme cases decrease
performance by a factor of 100 or higher,[5] the overhead
of acquiring and releasing a lock every time this method
is called seems unnecessary: once the initialization has
been completed, acquiring and releasing the locks would
appear unnecessary. Many programmers have attempted
to optimize this situation in the following manner:

Singleton& instance() { static Singleton s; return s; } 1. Check that the variable is initialized (without obtain-
ing the lock). If it is initialized, return it immedi-
92 CHAPTER 5. CONCURRENCY PATTERNS

ately. // Works with acquire/release semantics for volatile in

Java 1.5 and later // Broken under Java 1.4 and earlier
2. Obtain the lock.
semantics for volatile class Foo { private volatile Helper
3. Double-check whether the variable has already been helper; public Helper getHelper() { Helper result =
initialized: if another thread acquired the lock first, helper; if (result == null) { synchronized(this) { result
it may have already done the initialization. If so, = helper; if (result == null) { helper = result = new
return the initialized variable. Helper(); } } } return result; } // other functions and
members... }
4. Otherwise, initialize and return the variable.

// Broken multithreaded version // “Double-Checked Note the local variable result, which seems unnecessary.
Locking” idiom class Foo { private Helper helper; public The effect of this is that in cases where helper is already
Helper getHelper() { if (helper == null) { synchro- initialized (i.e., most of the time), the volatile field is only
nized(this) { if (helper == null) { helper = new Helper(); accessed once (due to “return result;" instead of “return
} } } return helper; } // other functions and members... } helper;"), which can improve the method’s overall perfor-
mance by as much as 25 percent.[7]
Intuitively, this algorithm seems like an efficient solution If the helper object is static (one per class loader), an al-
to the problem. However, this technique has many subtle ternative is the initialization-on-demand holder idiom[8]
problems and should usually be avoided. For example, (See Listing 16.6[9] from the previously cited text.)
consider the following sequence of events: // Correct lazy initialization in Java class Foo { private
static class HelperHolder { public static final Helper
1. Thread A notices that the value is not initialized, so helper = new Helper(); } public static Helper getHelper()
it obtains the lock and begins to initialize the value. { return HelperHolder.helper; } }
2. Due to the semantics of some programming lan-
guages, the code generated by the compiler is al- This relies on the fact that nested classes are not loaded
lowed to update the shared variable to point to a par- until they are referenced.
tially constructed object before A has finished per-
Semantics of final field in Java 5 can be employed to safely
forming the initialization. For example, in Java if a
publish the helper object without using volatile:[10]
call to a constructor has been inlined then the shared
variable may immediately be updated once the stor- public class FinalWrapper<T> { public final T value;
age has been allocated but before the inlined con- public FinalWrapper(T value) { this.value = value; }
structor initializes the object.[6] } public class Foo { private FinalWrapper<Helper>
helperWrapper; public Helper getHelper() { Final-
3. Thread B notices that the shared variable has been Wrapper<Helper> tempWrapper = helperWrapper;
initialized (or so it appears), and returns its value. if (tempWrapper == null) { synchronized(this) { if
Because thread B believes the value is already ini- (helperWrapper == null) { helperWrapper = new Fi-
tialized, it does not acquire the lock. If B uses the nalWrapper<Helper>(new Helper()); } tempWrapper =
object before all of the initialization done by A is helperWrapper; } } return tempWrapper.value; } }
seen by B (either because A has not finished initial-
izing it or because some of the initialized values in
the object have not yet percolated to the memory The local variable tempWrapper is required for correct-
B uses (cache coherence)), the program will likely ness: simply using helperWrapper for both null checks
crash. and the return statement could fail due to read reordering
allowed under the Java Memory Model.[11] Performance
One of the dangers of using double-checked locking in of this implementation is not necessarily better than the
J2SE 1.4 (and earlier versions) is that it will often appear volatile implementation.
to work: it is not easy to distinguish between a correct
implementation of the technique and one that has sub-
tle problems. Depending on the compiler, the interleav- 5.5.3 Usage in Microsoft .NET (Visual Ba-
ing of threads by the scheduler and the nature of other sic, C#)
concurrent system activity, failures resulting from an in-
correct implementation of double-checked locking may Double-checked locking can be implemented efficiently
only occur intermittently. Reproducing the failures can in .NET. A common usage pattern is to add double-
be difficult. checked locking to Singleton implementations:
As of J2SE 5.0, this problem has been fixed. The volatile public class MySingleton { private static object myLock
keyword now ensures that multiple threads handle the sin- = new object(); private static volatile MySingleton
gleton instance correctly. This new idiom is described in mySingleton = null; // 'volatile' is unnecessary in .NET
and . 2.0 and later private MySingleton() { } public static
5.5. DOUBLE-CHECKED LOCKING 93

MySingleton GetInstance() { if (mySingleton == null) { [6] Haggar, Peter (1 May 2002). “Double-checked locking
// 1st check lock (myLock) { if (mySingleton == null) { and the Singleton pattern”. IBM.
// 2nd (double) check mySingleton = new MySingleton();
// In .NET 1.1, write-release semantics are implicitly [7] Joshua Bloch “Effective Java, Second Edition”, p. 283-
handled by marking mySingleton with // 'volatile', which 284
inserts the necessary memory barriers between the
constructor call // and the write to mySingleton. The [8] Brian Goetz et al. Java Concurrency in Practice, 2006
barriers created by the lock are not sufficient // because pp348
the object is made visible before the lock is released. In
.NET 2.0 and later, // the lock is sufficient and 'volatile' [9] Goetz, Brian; et al. “Java Concurrency in Practice – list-
is not needed. } } } // In .NET 1.1, the barriers created ings on website”. Retrieved 21 October 2014.
by the lock are not sufficient because not all threads will
// acquire the lock. A fence for read-acquire semantics [10] Javamemorymodel-discussion mailing list
is needed between the test of mySingleton // (above)
and the use of its contents.This fence is automatically [11] Manson, Jeremy. “Date-Race-Ful Lazy Initialization for
inserted because mySingleton is // marked as 'volatile'. Performance – Java Concurrency (&c)". Retrieved 3 De-
// In .NET 2.0 and later, 'volatile' is not required. return cember 2016.
mySingleton; } }
[12] Albahari, Joseph (2010). “Threading in C#: Using
Threads”. C# 4.0 in a Nutshell. O'Reilly Media. ISBN 0-
In this example, the “lock hint” is the mySingleton object 596-80095-9. Lazy<T> actually implements […] double-
which is no longer null when fully constructed and ready checked locking. Double-checked locking performs an
for use. additional volatile read to avoid the cost of obtaining a
In .NET Framework 4.0, the Lazy<T> class was intro- lock if the object is already initialized.
duced, which internally uses double-checked locking by
default (ExecutionAndPublication mode) to store either
the exception that was thrown during construction, or the 5.5.6 External links
result of the function that was passed to Lazy<T>:[12]
public class MySingleton { private static read- • Issues with the double checked locking mechanism
only Lazy<MySingleton> _mySingleton = new captured in Jeu George’s Blogs Pure Virtuals
Lazy<MySingleton>(() => new MySingleton()); private
MySingleton() { } public static MySingleton Instance { • “Double Checked Locking” Description from the
get { return _mySingleton.Value; } } } Portland Pattern Repository

• “Double Checked Locking is Broken” Description

from the Portland Pattern Repository
5.5.4 See also
• Paper "C++ and the Perils of Double-Checked
• The Test and Test-and-set idiom for a low-level lock- Locking" (475 KB) by Scott Meyers and Andrei
ing mechanism. Alexandrescu
• Initialization-on-demand holder idiom for a thread-
safe replacement in Java. • Article "Double-checked locking: Clever, but bro-
ken" by Brian Goetz

5.5.5 References • Article "Warning! Threading in a multiprocessor

world" by Allen Holub
[1] Schmidt, D et al. Pattern-Oriented Software Architecture
Vol 2, 2000 pp353-363 • Double-checked locking and the Singleton pattern
[2] David Bacon et al. The “Double-Checked Locking is Bro-
ken” Declaration.
• Singleton Pattern and Thread Safety

[3] • volatile keyword in VC++ 2005

[4] Double-Checked Locking is Fixed In C++11

• Java Examples and timing of double check locking
[5] Boehm, Hans-J (Jun 2005). “Threads cannot be imple- solutions
mented as a library” (PDF). SIGPLAN Not. ACM Press.
40 (6): 261–268. doi:10.1145/1064978.1065042. • “More Effective Java With Google’s Joshua Bloch”.
94 CHAPTER 5. CONCURRENCY PATTERNS

5.6 Asynchronous method invoca- • Task-based Asynchronous Pattern (TAP) (used in

tion
In multithreaded computer programming, asynchronous
method invocation (AMI), also known as asyn-
chronous method calls or the asynchronous pattern
is a design pattern in which the call site is not blocked
while waiting for the called code to finish. Instead, the
calling thread is notified when the reply arrives. Polling
for a reply is an undesired option.
.NET Framework 4.0)[8]
Example The following example is loosely based on
a standard AMI style used in the .NET Framework.[9]
Given a method Accomplish, one adds two new methods
BeginAccomplish and EndAccomplish:
class Example { Result Accomplish(args …) IAsyn-
cResult BeginAccomplish(args …) Result EndAccom-
plish(IAsyncResult a) … }

5.6.1 Background Upon calling BeginAccomplish, the client immediately

receives an object of type AsyncResult (which imple-
AMI is a design pattern for asynchronous invocation of ments the IAsyncResult interface), so it can continue the
potentially long-running methods of an object.[1] It is calling thread with unrelated work. In the simplest case,
equivalent to the IOU pattern described in 1996 by Al- eventually there is no more such work, and the client calls
lan Vermeulen.[2][3] EndAccomplish (passing the previously received object),
which blocks until the method has completed and the
In most programming languages a called method is exe- result is available.[10] The AsyncResult object normally
cuted synchronously, i.e. in the thread of execution from provides at least a method that allows the client to query
which it is invoked. If the method needs a long time to whether the long-running method has already completed:
completion, e.g. because it is loading data over the in-
ternet, the calling thread is blocked until the method has interface IAsyncResult { bool HasCompleted() … }
finished. When this is not desired, it is possible to start
a “worker thread” and invoke the method from there. In One can also pass a callback method to BeginAccom-
most programming environments this requires many lines plish, to be invoked when the long-running method com-
of code, especially if care is taken to avoid the overhead pletes. It typically calls EndAccomplish to obtain the
that may be caused by creating many threads. AMI solves return value of the long-running method. A problem
this problem in that it augments a potentially long-running with the callback mechanism is that the callback func-
(“synchronous”) object method with an “asynchronous” tion is naturally executed in the worker thread (rather
variant that returns immediately, along with additional than in the original calling thread), which may cause race
methods that make it easy to receive notification of com- conditions.[11][12]
pletion, or to wait for completion at a later time.
In the .NET Framework documentation, the term event-
One common use of AMI is in the active object design based asynchronous pattern refers to an alternative API
pattern. Alternatives are synchronous method invocation style (available since .NET 2.0) using a method named
and future objects.[4] An example for an application that AccomplishAsync instead of BeginAccomplish.[13][14] A
may make use of AMI is a web browser that needs to superficial difference is that in this style the return value
display a web page even before all images are loaded. of the long-running method is passed directly to the call-
back method. Much more importantly, the API uses a
special mechanism to run the callback method (which re-
5.6.2 Implementations sides in an event object of type AccomplishCompleted)
in the same thread in which BeginAccomplish was called.
Java class This eliminates the danger of race conditions, making
the API easier to use and suitable for software compo-
FutureTask class[5] in Java use events to solve the same nents; on the other hand this implementation of the pat-
problem. This pattern is a variant of AMI whose imple- tern comes with additional object creation and synchro-
mentation carries more overhead, but it is useful for ob- nization overhead.[15]
jects representing software components.

5.6.3 References
.NET Framework
[1] “Asynchronous Method Invocation”. Distributed Pro-
gramming with Ice. ZeroC, Inc. Archived from the origi-
• Asynchronous Programming Model (APM) pattern
nal on 5 January 2008. Retrieved 22 November 2008.
(used before .NET Framework 2.0)[6]
[2] Vermeulen, Allan (June 1996). “An Asynchronous De-
• Event-based Asynchronous Pattern (EAP) (used in sign Pattern”. Dr. Dobb’s Journal. Retrieved 22 Novem-
.NET Framework 2.0)[7] ber 2008.
5.7. GUARDED SUSPENSION 95

[3] Nash, Trey (2007). “Threading in C#". Accelerated C#
2008. Apress. ISBN 978-1-59059-873-3.
[4] Lavender, R. Greg; Douglas C. Schmidt. “Active Object”
(PDF). Retrieved 22 November 2008.
[5] “Class FutureTask”. Oracle. 2011. Retrieved 2015-06-
29.
[6] “Asynchronous Programming Model”. Microsoft. 2015.
Retrieved 2015-06-29.
5.7 Guarded suspension
In concurrent programming, guarded suspension[1] is a
software design pattern for managing operations that re-
quire both a lock to be acquired and a precondition to
be satisfied before the operation can be executed. The
guarded suspension pattern is typically applied to method
calls in object-oriented programs, and involves suspend-
ing the method call, and the calling thread, until the pre-
condition (acting as a guard) is satisfied.

[7] “Event-based Asynchronous Pattern Overview”. Mi-

crosoft. 2015. Retrieved 2015-06-29. 5.7.1 Usage
[8] “Task-based Asynchronous Pattern”. Microsoft. 2015. Because it is blocking, the guarded suspension pattern
Retrieved 2015-06-29. is generally only used when the developer knows that a
method call will be suspended for a finite and reasonable
[9] “Asynchronous Programming Design Patterns”. .NET
period of time. If a method call is suspended for too long,
Framework Developer’s Guide. Microsoft Developer Net-
work. Archived from the original on 22 November 2008. then the overall program will slow down or stop, wait-
Retrieved 22 November 2008. ing for the precondition to be satisfied. If the developer
knows that the method call suspension will be indefinite
[10] “Asynchronous Programming Overview”. .NET Frame- or for an unacceptably long period, then the balking pat-
work Developer’s Guide. Microsoft Developer Network. tern may be preferred.
Archived from the original on 7 December 2008. Re-
trieved 22 November 2008.
5.7.2 Implementation
[11] “Using an AsyncCallback Delegate to End an Asyn-
chronous Operation”. .NET Framework Developer’s In Java, the Object class provides the wait() and notify()
Guide. Microsoft Developer Network. Archived from the methods to assist with guarded suspension. In the imple-
original on 23 December 2008. Retrieved 22 November
mentation below, originally found in Kuchana (2004), if
2008.
there is no precondition satisfied for the method call to be
[12] “Concurrency Issues”. Distributed Programming with Ice.
successful, then the method will wait until it finally enters
ZeroC, Inc. Archived from the original on 28 March a valid state.
2008. Retrieved 22 November 2008. public class Example { synchronized void guarded-
Method() { while (!preCondition()) { try { // Continue
[13] Christian Nagel; Bill Evjen; Jay Glynn; Karli Watson to wait wait(); // … } catch (InterruptedException e) {
& Morgan Skinner (2008). “Event-based Asynchronous
// … } } // Actual task implementation } synchronized
Pattern”. Professional C# 2008. Wiley. pp. 570–571.
void alterObjectStateMethod() { // Change the object
ISBN 9780470191378.
state // … // Inform waiting threads notify(); } }
[14] “Multithreaded Programming with the Event-based Asyn-
chronous Pattern”. .NET Framework Developer’s Guide. An example of an actual implementation would be a
Microsoft Developer Network. Archived from the origi- queue object with a get method that has a guard to de-
nal on 25 December 2008. Retrieved 22 November 2008. tect when there are no items in the queue. Once the “put”
method notifies the other methods (for example, a get()
[15] “Deciding When to Implement the Event-based Asyn-
method), then the get() method can exit its guarded state
chronous Pattern”. .NET Framework Developer’s Guide.
Microsoft Developer Network. Archived from the origi-
and proceed with a call. Once the queue is empty, then
nal on 22 November 2008. Retrieved 22 November 2008. the get() method will enter a guarded state once again.

5.6.4 Further reading 5.7.3 See also

• Read write lock pattern
• Chris Sells & Ian Griffiths (2007). “Appendix
C.3: The Event-Based Asynchronous Pattern”. Pro- • Balking pattern is an alternative pattern for dealing
gramming WPF. O'Reilly. pp. 747–749. ISBN with a precondition
9780596510374.
• Guarded commands includes a similar language
• Using asynchronous method calls in C# construct
96 CHAPTER 5. CONCURRENCY PATTERNS

5.7.4 Notes multiprocessor shared-memory machines. Proper sup-

port for locks in a multiprocessor environment can re-
[1] Lea, Doug (2000). Concurrent Programming in Java Sec- quire quite complex hardware or software support, with
ond Edition. Reading, MA: Addison-Wesley. ISBN 0- substantial synchronization issues.
201-31009-0.
The reason an atomic operation is required is because of
concurrency, where more than one task executes the same
5.7.5 References logic. For example, consider the following C code:
if(lock == 0) { // lock free, set it lock = myPID; }
• Kuchana, Partha (2004). “Software Architecture
Design Patterns in Java”. Boca Raton, Florida:
Auerbach Publications.. The above example does not guarantee that the task has
the lock, since more than one task can be testing the lock
at the same time. Since both tasks will detect that the lock
is free, both tasks will attempt to set the lock, not know-
5.8 Lock ing that the other task is also setting the lock. Dekker’s
or Peterson’s algorithm are possible substitutes if atomic
In computer science, a lock or mutex (from mutual ex- locking operations are not available.
clusion) is a synchronization mechanism for enforcing
limits on access to a resource in an environment where Careless use of locks can result in deadlock or livelock.
there are many threads of execution. A lock is designed A number of strategies can be used to avoid or recover
to enforce a mutual exclusion concurrency control policy. from deadlocks or livelocks, both at design-time and at
run-time. (The most common strategy is to standard-
ize the lock acquisition sequences so that combinations
5.8.1 Types of inter-dependent locks are always acquired in a specif-
ically defined “cascade” order.)
Generally, locks are advisory locks, where each thread co- Some languages do support locks syntactically. An ex-
operates by acquiring the lock before accessing the corre- ample in C# follows:
sponding data. Some systems also implement mandatory
locks, where attempting unauthorized access to a locked class Account { // this is a monitor of an account long
resource will force an exception in the entity attempting val = 0; object thisLock = new object(); public void
to make the access. deposit(const long x) { lock(thisLock) { // only one
thread at a time may execute this statement val += x; } }
The simplest type of lock is a binary semaphore. It public void withdraw(const long x) { lock(thisLock) { //
provides exclusive access to the locked data. Other only one thread at a time may execute this statement val
schemes also provide shared access for reading data. -= x; } } }
Other widely implemented access modes are exclusive,
intend-to-exclude and intend-to-upgrade.
The code lock(this) can lead to problems if the instance
Another way to classify locks is by what happens when the can be accessed publicly.[1]
lock strategy prevents progress of a thread. Most locking
designs block the execution of the thread requesting the Similar to Java, C# can also synchronize entire meth-
lock until it is allowed to access the locked resource. With ods, by [2][3]
using the MethodImplOptions.Synchronized
a spinlock, the thread simply waits (“spins”) until the lock attribute.
becomes available. This is efficient if threads are blocked [MethodImpl(MethodImplOptions.Synchronized)] pub-
for a short time, because it avoids the overhead of op- lic void someMethod() { // do stuff }
erating system process re-scheduling. It is inefficient if
the lock is held for a long time, or if the progress of the
thread that is holding the lock depends on preemption of
the locked thread. 5.8.2 Granularity
Locks typically require hardware support for efficient im-
plementation. This support usually takes the form of one Before being introduced to lock granularity, one needs to
or more atomic instructions such as "test-and-set", "fetch- understand three concepts about locks:
and-add" or "compare-and-swap". These instructions al-
low a single process to test if the lock is free, and if free, • lock overhead: the extra resources for using locks,
acquire the lock in a single atomic operation. like the memory space allocated for locks, the CPU
Uniprocessor architectures have the option of using time to initialize and destroy locks, and the time for
uninterruptable sequences of instructions—using spe- acquiring or releasing locks. The more locks a pro-
cial instructions or instruction prefixes to disable inter- gram uses, the more overhead associated with the
rupts temporarily—but this technique does not work for usage;
5.8. LOCK
• lock contention: this occurs whenever one process
or thread attempts to acquire a lock held by another
process or thread. The more fine-grained the avail-
able locks, the less likely one process/thread will re-
quest a lock held by the other. (For example, locking
a row rather than the entire table, or locking a cell
rather than the entire row.);
• deadlock: the situation when each of at least two
tasks is waiting for a lock that the other task holds.
Unless something is done, the two tasks will wait
forever.
There is a tradeoff between decreasing lock overhead and
decreasing lock contention when choosing the number of
locks in synchronization.
An important property of a lock is its granularity. The
granularity is a measure of the amount of data the lock
is protecting. In general, choosing a coarse granularity (a
small number of locks, each protecting a large segment of
data) results in less lock overhead when a single process
is accessing the protected data, but worse performance
when multiple processes are running concurrently. This
is because of increased lock contention. The more coarse
the lock, the higher the likelihood that the lock will stop
an unrelated process from proceeding. Conversely, using
a fine granularity (a larger number of locks, each pro-
tecting a fairly small amount of data) increases the over-
head of the locks themselves but reduces lock contention.
Granular locking where each process must hold multiple
locks from a common set of locks can create subtle lock
dependencies. This subtlety can increase the chance that
a programmer will unknowingly introduce a deadlock.
In a database management system, for example, a lock
could protect, in order of decreasing granularity, part of
a field, a field, a record, a data page, or an entire table.
Coarse granularity, such as using table locks, tends to give
the best performance for a single user, whereas fine gran-
ularity, such as record locks, tends to give the best per-
formance for multiple users.
5.8.3 Database locks
Main article: Lock (database)
Database locks can be used as a means of ensuring trans-
action synchronicity. i.e. when making transaction pro-
cessing concurrent (interleaving transactions), using 2-
phased locks ensures that the concurrent execution of the
transaction turns out equivalent to some serial ordering
of the transaction. However, deadlocks become an un-
fortunate side-effect of locking in databases. Deadlocks
are either prevented by pre-determining the locking or-
der between transactions or are detected using waits-for
graphs. An alternate to locking for database synchronic-
ity while avoiding deadlocks involves the use of totally
ordered global timestamps.
97
There are mechanisms employed to manage the actions
of multiple concurrent users on a database—the purpose
is to prevent lost updates and dirty reads. The two types
of locking are pessimistic locking and optimistic locking:
• Pessimistic locking: a user who reads a record, with
the intention of updating it, places an exclusive lock
on the record to prevent other users from manipulat-
ing it. This means no one else can manipulate that
record until the user releases the lock. The down-
side is that users can be locked out for a very long
time, thereby slowing the overall system response
and causing frustration.
Where to use pessimistic locking:
this is mainly used in environments
where data-contention (the degree
of users request to the database
system at any one time) is heavy;
where the cost of protecting data
through locks is less than the cost of
rolling back transactions, if concur-
rency conflicts occur. Pessimistic
concurrency is best implemented
when lock times will be short,
as in programmatic processing of
records. Pessimistic concurrency
requires a persistent connection to
the database and is not a scalable
option when users are interacting
with data, because records might be
locked for relatively large periods
of time. It is not appropriate for use
in Web application development.
• Optimistic locking: this allows multiple concurrent
users access to the database whilst the system keeps
a copy of the initial-read made by each user. When a
user wants to update a record, the application deter-
mines whether another user has changed the record
since it was last read. The application does this by
comparing the initial-read held in memory to the
database record to verify any changes made to the
record. Any discrepancies between the initial-read
and the database record violates concurrency rules
and hence causes the system to disregard any up-
date request. An error message is generated and
the user is asked to start the update process again.
It improves database performance by reducing the
amount of locking required, thereby reducing the
load on the database server. It works efficiently with
tables that require limited updates since no users are
locked out. However, some updates may fail. The
downside is constant update failures due to high vol-
umes of update requests from multiple concurrent
users - it can be frustrating for users.
Where to use optimistic lock-
ing: this is appropriate in envi-
98 CHAPTER 5. CONCURRENCY PATTERNS

ronments where there is low con- • Convoying: all other threads have to wait if a thread
tention for data, or where read-only holding a lock is descheduled due to a time-slice in-
access to data is required. Op- terrupt or page fault.
timistic concurrency is used ex-
tensively in .NET to address the Some concurrency control strategies avoid some or all
needs of mobile and disconnected of these problems. For example, a funnel or serializing
applications,[4] where locking data tokens can avoid the biggest problem: deadlocks. Al-
rows for prolonged periods of time ternatives to locking include non-blocking synchroniza-
would be infeasible. Also, main- tion methods, like lock-free programming techniques and
taining record locks requires a per- transactional memory. However, such alternative meth-
sistent connection to the database ods often require that the actual lock mechanisms be im-
server, which is not possible in dis- plemented at a more fundamental level of the operating
connected applications. software. Therefore, they may only relieve the applica-
tion level from the details of implementing locks, with
the problems listed above still needing to be dealt with
5.8.4 Disadvantages beneath the application.
In most cases, proper locking depends on the CPU pro-
Lock-based resource protection and thread/process syn- viding a method of atomic instruction stream synchro-
chronization have many disadvantages: nization (for example, the addition or deletion of an item
into a pipeline requires that all contemporaneous opera-
• Contention: some threads/processes have to wait tions needing to add or delete other items in the pipe be
until a lock (or a whole set of locks) is released. If suspended during the manipulation of the memory con-
one of the threads holding a lock dies, stalls, blocks, tent required to add or delete the specific item). There-
or enters an infinite loop, other threads waiting for fore, an application can often be more robust when it rec-
the lock may wait forever. ognizes the burdens it places upon an operating system
and is capable of graciously recognizing the reporting of
• Overhead: the use of locks adds overhead for each impossible demands.
access to a resource, even when the chances for col-
lision are very rare. (However, any chance for such Lack of composability
collisions is a race condition.)
One of lock-based programming’s biggest problems is
• Debugging: bugs associated with locks are time de- that “locks don't compose": it is hard to combine small,
pendent and can be very subtle and extremely hard correct lock-based modules into equally correct larger
to replicate, such as deadlocks. programs without modifying the modules or at least
knowing about their internals. Simon Peyton Jones (an
• Instability: the optimal balance between lock over- advocate of software transactional memory) gives the fol-
head and lock contention can be unique to the prob- lowing example of a banking application:[5] design a class
lem domain (application) and sensitive to design, Account that allows multiple concurrent clients to deposit
implementation, and even low-level system architec- or withdraw money to an account; and give an algorithm
tural changes. These balances may change over the to transfer money from one account to another. The lock-
life cycle of an application and may entail tremen- based solution to the first part of the problem is:
dous changes to update (re-balance).
class Account: member balance : Integer member mu-
• Composability: locks are only composable (e.g., tex : Lock method deposit(n : Integer) mutex.lock() bal-
managing multiple concurrent locks in order to ance ← balance + n mutex.unlock() method withdraw(n
atomically delete item X from table A and insert : Integer) deposit(−n)
X into table B) with relatively elaborate (overhead) The second part of the problem is much more compli-
software support and perfect adherence by applica- cated. A transfer routine that is correct for sequential
tions programming to rigorous conventions. programs would be

• Priority inversion: a low-priority thread/process function transfer(from : Account, to : Account, amount

holding a common lock can prevent high-priority
threads/processes from proceeding. Priority inheri-
tance can be used to reduce priority-inversion du-
ration. The priority ceiling protocol can be used
on uniprocessor systems to minimize the worst-
case priority-inversion duration, as well as prevent
deadlock.
: integer) from.withdraw(amount) to.deposit(amount)
In a concurrent program, this algorithm is incorrect be-
cause when one thread is halfway through transfer, an-
other might observe a state where amount has been with-
drawn from the first account, but not yet deposited into
the other account: money has gone missing from the sys-
tem. This problem can only be fixed completely by taking
5.8. LOCK 99

locks on both account prior to changing any of the two ac- • x86 assembly provides the LOCK prefix on certain
counts, but then the locks have to be taken according to operations to guarantee their atomicity.
some arbitrary, global ordering to prevent deadlock:
• PHP provides a file based locking [18] as well as a
function transfer(from : Account, to : Account, Mutex class in the pthreads extension. [19]
amount : integer) if from < to // arbitrary order-
ing on the locks from.lock() to.lock() else to.lock()
from.lock() from.withdraw(amount) to.deposit(amount) 5.8.6 See also
from.unlock() to.unlock()
• Critical section
This solution gets more complicated when more locks are
involved, and the transfer function needs to know about • Double-checked locking
all of the locks, so they cannot be hidden.
• File locking

5.8.5 Language support • Lock-free and wait-free algorithms

• Monitor (synchronization)
See also: Barrier (computer science)
• Mutual exclusion
Programming languages vary in their support for synchro- • Read/write lock pattern
nization:
• Semaphore (programming)
• The ISO/IEC C standard provides a standard mutual
exclusion (locks) API since C11. The current
5.8.7 References
ISO/IEC C++ standard supports threading facilities
since C++11. The OpenMP standard is supported [1] “lock Statement (C# Reference)".
by some compilers, and allows critical sections to
be specified using pragmas. The POSIX pthread [2] “ThreadPoolPriority, and MethodImplAttribute”. http:
API provides lock support.[6] Visual C++ provides //msdn.microsoft.com/en-us/magazine/cc163896.aspx:
the synchronize attribute of methods to be synchro- MSDN. p. ??. Retrieved 2011-11-22.
nized, but this is specific to COM objects in the [3] “C# From a Java Developer’s Perspective”. http://www.
Windows architecture and Visual C++ compiler.[7] 25hoursaday.com/CsharpVsJava.html#attributes. Re-
C and C++ can easily access any native operating trieved 2011-11-22.
system locking features.
[4] “Designing Data Tier Components and Passing Data
• Objective-C provides the keyword Through Tiers”. Microsoft. August 2002. Retrieved
@synchronized[8] to put locks on blocks of 2008-05-30.
code and also provides the classes NSLock,[9]
[5] Peyton Jones, Simon (2007). “Beautiful concurrency”
NSRecursiveLock,[10] and NSConditionLock[11] (PDF). In Wilson, Greg; Oram, Andy. Beautiful Code:
along with the NSLocking protocol[12] for locking Leading Programmers Explain How They Think. O'Reilly.
as well.
[6] Marshall, Dave (March 1999). “Mutual Exclusion
• C# provides the lock keyword on a thread to ensure Locks”. Retrieved 2008-05-30.
its exclusive access to a resource.
[7] “Synchronize”. msdn.microsoft.com. Retrieved 2008-
• VB.NET provides a SyncLock keyword like C#'s 05-30.
lock keyword. [8] “Apple Threading Reference”. Apple, inc. Retrieved
2009-10-17.
• Java provides the keyword synchronized to lock
code blocks, methods or objects[13] and libraries fea- [9] “NSLock Reference”. Apple, inc. Retrieved 2009-10-17.
turing concurrency-safe data structures.
[10] “NSRecursiveLock Reference”. Apple, inc. Retrieved
• Python provides a low-level mutex mechanism with- 2009-10-17.
out a keyword.[14]
[11] “NSConditionLock Reference”. Apple, inc. Retrieved
• Ruby provides a low-level mutex object and no 2009-10-17.
keyword.[15] [12] “NSLocking Protocol Reference”. Apple, inc. Retrieved
2009-10-17.
• Ada provides protected objects that have visible
protected subprograms or entries[16] as well as [13] “Synchronization”. Sun Microsystems. Retrieved 2008-
rendezvous.[17] 05-30.
100 CHAPTER 5. CONCURRENCY PATTERNS

[14] Lundh, Fredrik (July 2007). “Thread Synchronization 5.9.1 Mutual exclusion
Mechanisms in Python”. Retrieved 2008-05-30.
As a simple example, consider a thread-safe object for
[15] “Programming Ruby: Threads and Processes”. 2001. Re- performing transactions on a bank account:
trieved 2008-05-30.
monitor class Account { private int balance := 0 in-
[16] ISO/IEC 8652:2007. “Protected Units and Protected Ob- variant balance >= 0 public method boolean with-
jects”. Ada 2005 Reference Manual. Retrieved 2010-02- draw(int amount) precondition amount >= 0 { if bal-
27. A protected object provides coordinated access to ance < amount { return false } else { balance := bal-
shared data, through calls on its visible protected opera- ance - amount return true } } public method deposit(int
tions, which can be protected subprograms or protected amount) precondition amount >= 0 { balance := balance
entries. + amount } }
[17] ISO/IEC 8652:2007. “Example of Tasking and Synchro- While a thread is executing a method of a thread-safe ob-
nization”. Ada 2005 Reference Manual. Retrieved 2010- ject, it is said to occupy the object, by holding its mutex
02-27. (lock). Thread-safe objects are implemented to enforce
that at each point in time, at most one thread may occupy
[18] http://php.net/manual/en/function.flock.php. Missing or the object. The lock, which is initially unlocked, is locked
empty |title= (help) at the start of each public method, and is unlocked at each
return from each public method.
[19] http://php.net/manual/en/class.mutex.php. Missing or
empty |title= (help) Upon calling one of the methods, a thread must wait un-
til no other thread is executing any of the thread-safe ob-
ject’s methods before starting execution of its method.
5.8.8 External links Note that without this mutual exclusion, in the present
example, two threads could cause money to be lost or
gained for no reason. For example, two threads with-
• Tutorial on Locks and Critical Sections
drawing 1000 from the account could both return true,
while causing the balance to drop by only 1000, as fol-
lows: first, both threads fetch the current balance, find it
5.9 Monitor greater than 1000, and subtract 1000 from it; then, both
threads store the balance and return.
In concurrent programming, a monitor is a synchroniza- The syntactic sugar “monitor class” in the above example
tion construct that allows threads to have both mutual ex- is implementing the following basic representation of the
clusion and the ability to wait (block) for a certain con- code, by wrapping each function’s execution in mutexes:
dition to become true. Monitors also have a mechanism
class Account { private lock myLock private int bal-
for signalling other threads that their condition has been
ance := 0 invariant balance >= 0 public method boolean
met. A monitor consists of a mutex (lock) object and
withdraw(int amount) precondition amount >= 0 { my-
condition variables. A condition variable is basically
Lock.acquire() try { if balance < amount { return false
a container of threads that are waiting for a certain condi-
} else { balance := balance - amount return true } } fi-
tion. Monitors provide a mechanism for threads to tem-
nally { myLock.release() } } public method deposit(int
porarily give up exclusive access in order to wait for some
amount) precondition amount >= 0 { myLock.acquire()
condition to be met, before regaining exclusive access and
try { balance := balance + amount } finally { my-
resuming their task.
Lock.release() } } }
Another definition of monitor is a thread-safe class,
object, or module that uses wrapped mutual exclusion in
order to safely allow access to a method or variable by 5.9.2 Condition variables
more than one thread. The defining characteristic of a
monitor is that its methods are executed with mutual ex-
Problem statement
clusion: At each point in time, at most one thread may be
executing any of its methods. By using one or more con-
dition variables it can also provide the ability for threads For many applications, mutual exclusion is not enough.
to wait on a certain condition (thus using the above def- Threads attempting an operation may need to wait until
inition of a “monitor”). For the rest of this article, this some condition P holds true. A busy waiting loop
sense of “monitor” will be referred to as a “thread-safe while not( P ) do skip
object/class/module”. will not work, as mutual exclusion will prevent any other
Monitors were invented by Per Brinch Hansen[1] and C. thread from entering the monitor to make the condition
A. R. Hoare,[2] and were first implemented in Brinch true. Other “solutions” exist such as having a loop that un-
Hansen’s Concurrent Pascal language.[3] locks the monitor, waits a certain amount of time, locks
5.9. MONITOR
the monitor and check for the condition P. Theoretically,
it works and will not deadlock, but issues arise. It’s hard to
decide an appropriate amount of waiting time, too small
and the thread will hog the CPU, too big and it will be
apparently unresponsive. What is needed is a way to sig-
nal the thread when the condition P is true (or could be
true).
Case study: classic bounded producer/consumer
problem
A classic concurrency problem is that of the bounded
producer/consumer, in which there is a queue or ring
buffer of tasks with a maximum size, with one or more
threads being “producer” threads that add tasks to the
queue, and one or more other threads being “consumer”
threads that take tasks out of the queue. The queue is as-
sumed to be non–thread-safe itself, and it can be empty,
full, or between empty and full. Whenever the queue is
full of tasks, then we need the producer threads to block
until there is room from consumer threads dequeueing
tasks. On the other hand, whenever the queue is empty,
then we need the consumer threads to block until more
tasks are available due to producer threads adding them.
As the queue is a concurrent object shared between
threads, accesses to it must be made atomic, because
the queue can be put into an inconsistent state dur-
ing the course of the queue access that should never
be exposed between threads. Thus, any code that ac-
cesses the queue constitutes a critical section that must
be synchronized by mutual exclusion. If code and pro-
cessor instructions in critical sections of code that ac-
cess the queue could be interleaved by arbitrary context
switches between threads on the same processor or by
simultaneously-running threads on multiple processors,
then there is a risk of exposing inconsistent state and caus-
ing race conditions.
Incorrect without synchronization A naïve approach
is to design the code with busy-waiting and no synchro-
nization, making the code subject to race conditions:
global RingBuffer queue; // A thread-unsafe ring-buffer
of tasks. // Method representing each producer thread’s
behavior: public method producer(){ while(true){ task
myTask=...; // Producer makes some new task to be
added. while(queue.isFull()){} // Busy-wait until the
queue is non-full. queue.enqueue(myTask); // Add the
task to the queue. } } // Method representing each
consumer thread’s behavior: public method consumer(){
while(true){ while (queue.isEmpty()){} // Busy-wait
until the queue is non-empty. myTask=queue.dequeue();
// Take a task off of the queue. doStuff(myTask); // Go This method assures that an inconsistent state does not
off and do something with the task. } } occur, but wastes CPU resources due to the unnecessary
busy-waiting. Even if the queue is empty and producer
This code has a serious problem in that accesses to threads have nothing to add for a long time, consumer
the queue can be interrupted and interleaved with other threads are always busy-waiting unnecessarily. Likewise,
101
threads’ accesses to the queue. The queue.enqueue and
queue.dequeue methods likely have instructions to up-
date the queue’s member variables such as its size, begin-
ning and ending positions, assignment and allocation of
queue elements, etc. In addition, the queue.isEmpty() and
queue.isFull() methods read this shared state as well. If
producer/consumer threads are allowed to be interleaved
during the calls to enqueue/dequeue, then inconsistent
state of the queue can be exposed leading to race con-
ditions. In addition, if one consumer makes the queue
empty in-between another consumer’s exiting the busy-
wait and calling “dequeue”, then the second consumer
will attempt to dequeue from an empty queue leading to
an error. Likewise, if a producer makes the queue full
in-between another producer’s exiting the busy-wait and
calling “enqueue”, then the second producer will attempt
to add to a full queue leading to an error.
Spin-waiting One naive approach to achieve synchro-
nization, as alluded to above, is to use "spin-waiting", in
which a mutex is used to protect the critical sections of
code and busy-waiting is still used, with the lock being
acquired and released in between each busy-wait check.
global RingBuffer queue; // A thread-unsafe ring-buffer
of tasks. global Lock queueLock; // A mutex for
the ring-buffer of tasks. // Method representing each
producer thread’s behavior: public method producer(){
while(true){ task myTask=...; // Producer makes some
new task to be added. queueLock.acquire(); // Acquire
lock for initial busy-wait check. while(queue.isFull()){
// Busy-wait until the queue is non-full. queue-
Lock.release(); // Drop the lock temporarily to allow a
chance for other threads // needing queueLock to run so
that a consumer might take a task. queueLock.acquire();
// Re-acquire the lock for the next call to “queue.isFull()".
} queue.enqueue(myTask); // Add the task to the queue.
queueLock.release(); // Drop the queue lock until we
need it again to add the next task. } } // Method
representing each consumer thread’s behavior: public
method consumer(){ while(true){ queueLock.acquire();
// Acquire lock for initial busy-wait check. while
(queue.isEmpty()){ // Busy-wait until the queue is
non-empty. queueLock.release(); // Drop the lock
temporarily to allow a chance for other threads // needing
queueLock to run so that a producer might add a task.
queueLock.acquire(); // Re-acquire the lock for the next
call to “queue.isEmpty()". } myTask=queue.dequeue();
// Take a task off of the queue. queueLock.release(); //
Drop the queue lock until we need it again to take off the
next task. doStuff(myTask); // Go off and do something
with the task. } }
102
even if consumers are blocked for a long time on pro-
cessing their current tasks and the queue is full, producers
are always busy-waiting. This is a wasteful mechanism.
What is needed is a way to make producer threads block
until the queue is non-full, and a way to make consumer
threads block until the queue is non-empty.
(N.B.: Mutexes themselves can also be spin-locks which
involve busy-waiting in order to get the lock, but in order
to solve this problem of wasted CPU resources, we as-
sume that queueLock is not a spin-lock and properly uses
a blocking lock queue itself.)
Condition variables
The solution is to use condition variables. Conceptually
a condition variable is a queue of threads, associated with
a monitor, on which a thread may wait for some condition
to become true. Thus each condition variable c is associ-
ated with an assertion P . While a thread is waiting on a
condition variable, that thread is not considered to occupy
the monitor, and so other threads may enter the monitor
to change the monitor’s state. In most types of monitors,
these other threads may signal the condition variable c to
indicate that assertion P is true in the current state.
Thus there are two main operations on condition vari-
ables:
• wait c, m, where c is a condition variable and m is
a mutex (lock) associated with the monitor. This
operation is called by a thread that needs to wait un-
til the assertion P is true before proceeding. While
the thread is waiting, it does not occupy the moni-
tor. The function, and fundamental contract, of the
“wait” operation, is to do the following steps:
1. Atomically:
(a) release the mutex m,
(b) move this thread from the
“ready queue” to c's “wait-
queue” (a.k.a. “sleep-queue”)
of threads, and
(c) sleep this thread. (Context
is synchronously yielded to an-
other thread.)
2. Once this thread is subsequently noti-
fied/signalled (see below) and resumed, then
automatically re-acquire the mutex m.
Steps 1a and 1b can occur in either order,
with 1c usually occurring after them.
While the thread is sleeping and in c's
wait-queue, the next program counter to
be executed is at step 2, in the middle
of the “wait” function/subroutine. Thus,
the thread sleeps and later wakes up in
the middle of the “wait” operation.
CHAPTER 5. CONCURRENCY PATTERNS
The atomicity of the operations within
step 1 is important to avoid race condi-
tions that would be caused by a preemp-
tive thread switch in-between them. One
failure mode that could occur if these
were not atomic is a missed wakeup, in
which the thread could be on c's sleep-
queue and have released the mutex, but
a preemptive thread switch occurred be-
fore the thread went to sleep, and an-
other thread called a signal/notify oper-
ation (see below) on c moving the first
thread back out of c's queue. As soon
as the first thread in question is switched
back to, its program counter will be at
step 1c, and it will sleep and be unable to
be woken up again, violating the invari-
ant that it should have been on c's sleep-
queue when it slept. Other race condi-
tions depend on the ordering of steps 1a
and 1b, and depend on where a context
switch occurs.
• signal c, also known as notify c, is called by a thread
to indicate that the assertion P is true. Depending
on the type and implementation of the monitor, this
moves one or more threads from c’s sleep-queue to
the “ready queue” or another queues for it to be exe-
cuted. It is usually considered a best practice to per-
form the “signal"/"notify” operation before releasing
mutex m that is associated with c, but as long as the
code is properly designed for concurrency and de-
pending on the threading implementation, it is often
also acceptable to release the lock before signalling.
Depending on the threading implementation, the or-
dering of this can have scheduling-priority ramifica-
tions. (Some authors instead advocate a preference
for releasing the lock before signalling.) A threading
implementation should document any special con-
straints on this ordering.
• broadcast c, also known as notifyAll c, is a
similar operation that wakes up all threads in
c’s wait-queue. This empties the wait-queue.
Generally, when more than one predicate con-
dition is associated with the same condition
variable, the application will require broad-
cast instead of signal because a thread wait-
ing for the wrong condition might be woken up
and then immediately go back to sleep without
waking up a thread waiting for the correct con-
dition that just became true. Otherwise, if the
predicate condition is one-to-one with the con-
dition variable associated with it, then signal
may be more efficient than broadcast.
As a design rule, multiple condition variables can be as-
sociated with the same mutex, but not vice versa. (This
is a one-to-many correspondence.) This is because the
5.9. MONITOR
predicate P is the same for all threads using the moni-
tor and must be protected with mutual exclusion from all
other threads that might cause the condition to be changed
or that might read it while the thread in question causes
it to be changed, but there may be different threads that
want to wait for a different condition on the same variable
requiring the same mutex to be used. In the producer-
consumer example described above, the queue must be
protected by a unique mutex object, m. The “producer”
threads will want to wait on a monitor using lock m and
a condition variable cf ull which blocks until the queue is
non-full. The “consumer” threads will want to wait on a
different monitor using the same mutex m but a different
condition variable cempty which blocks until the queue is
non-empty. It would (usually) never make sense to have
different mutexes for the same condition variable, but this
classic example shows why it often certainly makes sense
to have multiple condition variables using the same mu-
tex. A mutex used by one or more condition variables
(one or more monitors) may also be shared with code that
does not use condition variables (and which simply ac-
quires/releases it without any wait/signal operations), if
those critical sections do not happen to require waiting
for a certain condition on the concurrent data.
Monitor usage
The proper basic usage of a monitor is:
acquire(m); // Acquire this monitor’s lock. while
(!p) { // While the condition/predicate/assertion that
we are waiting for is not true... wait(m, cv); // Wait
on this monitor’s lock and condition variable. } //
... Critical section of code goes here ... signal(cv2);
-- OR -- notifyAll(cv2); // cv2 might be the same as
cv or different. release(m); // Release this monitor’s lock.
To be more precise, this is the same pseudocode but with
more verbose comments to better explain what is going
on:
// ... (previous code) // About to enter the monitor.
// Acquire the advisory mutex (lock) associated with
the concurrent data that is shared between threads,
// to ensure that no two threads can be preemptively
interleaved or run simultaneously on different cores //
while executing in critical sections that read or write this
same concurrent data. // If another thread is holding
this mutex, then this thread will be sleeped (blocked)
and placed on // m’s sleep queue. (Mutex “m” shall not
be a spin-lock.) acquire(m); // Now, we are holding
the lock and can check the condition for the first time.
// The first time we execute the while loop condition
after the above “acquire”, we are asking, // “Does the
condition/predicate/assertion we are waiting for happen
to already be true?" while ( ! p() ) // “p” is any expression Solving the bounded producer/consumer problem
(e.g. variable or function-call) that checks the condition Having introduced the usage of condition variables, let’s
// and evaluates to boolean. This itself is a critical use it to revisit and solve the classic bounded pro-
103
section, so you *MUST* // be holding the lock when
executing this “while” loop condition! // If this is not
the first time the “while” condition is being checked,
then we are asking the question, // “Now that another
thread using this monitor has notified me and woken
me up and I have been // context-switched back to, did
the condition/predicate/assertion we are waiting on stay
true between // the time that I was woken up and the
time that I // re-acquired the lock inside the “wait” call
in the last iteration of this loop, // or did some other
thread cause the condition to become false again in the
meantime // thus making this a spurious wakeup? { // If
this is the first iteration of the loop, then the answer is
“no” -- the condition is not ready yet. // Otherwise, the
answer is: the latter. This was a spurious wakeup, some
other thread occurred first // and caused the condition to
become false again, and we must wait again. wait(m, cv);
// Temporarily prevent any other thread on any core from
doing operations on m or cv. // release(m) // Atomically
release lock “m” so other code using this concurrent data
// // can operate, move this thread to cv’s wait-queue so
that it will be notified // // sometime when the condition
becomes true, and sleep this thread. // // Re-enable other
threads and cores to do operations on m and cv. // //
Context switch occurs on this core. // // At some future
time, the condition we are waiting for becomes true,
// and another thread using this monitor (m, cv) does
either a signal/notify // that happens to wake this thread
up, or a notifyAll that wakes us up, meaning // that we
have been taken out of cv’s wait-queue. // // During this
time, other threads may be switched to that caused the
condition to become // false again, or the condition may
toggle one or more times, or it may happen to // stay
true. // // This thread is switched back to on some core.
// // acquire(m) // Lock “m” is re-acquired. // End this
loop iteration and re-check the “while” loop condition to
make sure the predicate is // still true. } // The condition
we are waiting for is true! // We are still holding the lock,
either from before entering the monitor or from the //
last execution of “wait”. // Critical section of code goes
here, which has a precondition that our predicate // must
be true. // This code might make cv’s condition false,
and/or make other condition variables’ // predicates true.
// Call signal/notify or notifyAll, depending on which
condition variables’ predicates // (who share mutex m)
have been made true or may have been made true, and
the monitor semantic type // being used. for (cv_x in
cvs_to_notify){ notify(cv_x); -- OR -- notifyAll(cv_x);
} // One or more threads have been woken up but will
block as soon as they try // to acquire m. // Release the
mutex so that notified thread(s) and others can enter //
their critical sections. release(m);
104 CHAPTER 5. CONCURRENCY PATTERNS

ducer/consumer problem. The classic solution is to use locks.

two monitors, comprising two condition variables shar- A variant of this solution could use a single condition vari-
ing one lock on the queue: able for both producers and consumers, perhaps named
global volatile RingBuffer queue; // A thread-unsafe “queueFullOrEmptyCV” or “queueSizeChangedCV”. In
ring-buffer of tasks. global Lock queueLock; // A this case, more than one condition is associated with
mutex for the ring-buffer of tasks. (Not a spin-lock.) the condition variable, such that the condition variable
global CV queueEmptyCV; // A condition variable represents a weaker condition than the conditions being
for consumer threads waiting for the queue to become checked by individual threads. The condition variable
non-empty. // Its associated lock is “queueLock”. global represents threads that are waiting for the queue to be
CV queueFullCV; // A condition variable for producer non-full and ones waiting for it to be non-empty. How-
threads waiting for the queue to become non-full. ever, doing this would require using notifyAll in all the
//Its associated lock is also “queueLock”. // Method threads using the condition variable and cannot use a reg-
representing each producer thread’s behavior: public ular signal. This is because the regular signal might wake
method producer(){ while(true){ task myTask=...; // up a thread of the wrong type whose condition has not yet
Producer makes some new task to be added. queue- been met, and that thread would go back to sleep without
Lock.acquire(); // Acquire lock for initial predicate a thread of the correct type getting signalled. For exam-
check. while(queue.isFull()){ // Check if the queue is ple, a producer might make the queue full and wake up
non-full. // Make the threading system atomically release another producer instead of a consumer, and the woken
queueLock, // enqueue this thread onto queueFullCV, producer would go back to sleep. In the complementary
and sleep this thread. wait(queueLock, queueFullCV); case, a consumer might make the queue empty and wake
// Then, “wait” automatically re-acquires “queueLock” up another consumer instead of a producer, and the con-
for re-checking // the predicate condition. } // Critical sumer would go back to sleep. Using notifyAll ensures
section that requires the queue to be non-full. // N.B.: that some thread of the right type will proceed as ex-
We are holding queueLock. queue.enqueue(myTask); pected by the problem statement.
// Add the task to the queue. // Now the queue is Here is the variant using only one condition variable and
guaranteed to be non-empty, so signal a consumer thread notifyAll:
// or all consumer threads that might be blocked waiting
for the queue to be non-empty: signal(queueEmptyCV); global volatile RingBuffer queue; // A thread-unsafe
-- OR -- notifyAll(queueEmptyCV); // End of critical ring-buffer of tasks. global Lock queueLock; // A
sections related to the queue. queueLock.release(); mutex for the ring-buffer of tasks. (Not a spin-lock.)
// Drop the queue lock until we need it again to add global CV queueFullOrEmptyCV; // A single condition
the next task. } } // Method representing each con- variable for when the queue is not ready for any thread
sumer thread’s behavior: public method consumer(){ // -- i.e., for producer threads waiting for the queue to
while(true){ queueLock.acquire(); // Acquire lock for become non-full // and consumer threads waiting for the
initial predicate check. while (queue.isEmpty()){ // queue to become non-empty. // Its associated lock is
Check if the queue is non-empty. // Make the threading “queueLock”. // Not safe to use regular “signal” because
system atomically release queueLock, // enqueue this it is associated with // multiple predicate conditions (as-
thread onto queueEmptyCV, and sleep this thread. sertions). // Method representing each producer thread’s
wait(queueLock, queueEmptyCV); // Then, “wait” behavior: public method producer(){ while(true){ task
automatically re-acquires “queueLock” for re-checking myTask=...; // Producer makes some new task to be
// the predicate condition. } // Critical section that added. queueLock.acquire(); // Acquire lock for initial
requires the queue to be non-empty. // N.B.: We are predicate check. while(queue.isFull()){ // Check if
holding queueLock. myTask=queue.dequeue(); // Take the queue is non-full. // Make the threading system
a task off of the queue. // Now the queue is guaranteed atomically release queueLock, // enqueue this thread
to be non-full, so signal a producer thread // or all onto the CV, and sleep this thread. wait(queueLock,
producer threads that might be blocked waiting for queueFullOrEmptyCV); // Then, “wait” automatically
the queue to be non-full: signal(queueFullCV); -- OR re-acquires “queueLock” for re-checking // the predicate
-- notifyAll(queueFullCV); // End of critical sections condition. } // Critical section that requires the queue
related to the queue. queueLock.release(); // Drop the to be non-full. // N.B.: We are holding queueLock.
queue lock until we need it again to take off the next queue.enqueue(myTask); // Add the task to the queue.
task. doStuff(myTask); // Go off and do something with // Now the queue is guaranteed to be non-empty, so
the task. } } signal all blocked threads // so that a consumer thread
will take a task: notifyAll(queueFullOrEmptyCV);
// Do not use “signal” (as it might wake up another
This ensures concurrency between the producer and con- producer instead). // End of critical sections related
sumer threads sharing the task queue, and blocks the
to the queue. queueLock.release(); // Drop the queue
threads that have nothing to do rather than busy-waiting lock until we need it again to add the next task. }
as shown in the aforementioned approach using spin-
} // Method representing each consumer thread’s
5.9. MONITOR
behavior: public method consumer(){ while(true){
queueLock.acquire(); // Acquire lock for initial predi-
cate check. while (queue.isEmpty()){ // Check if the
queue is non-empty. // Make the threading system
atomically release queueLock, // enqueue this thread
onto the CV, and sleep this thread. wait(queueLock,
queueFullOrEmptyCV); // Then, “wait” automatically
re-acquires “queueLock” for re-checking // the predicate
condition. } // Critical section that requires the queue
to be non-full. // N.B.: We are holding queueLock.
myTask=queue.dequeue(); // Take a task off of the
queue. // Now the queue is guaranteed to be non-full,
so signal all blocked threads // so that a producer thread
will take a task: notifyAll(queueFullOrEmptyCV); // Do
not use “signal” (as it might wake up another consumer
instead). // End of critical sections related to the queue.
queueLock.release(); // Drop the queue lock until we
need it again to take off the next task. doStuff(myTask);
// Go off and do something with the task. } }
Synchronization primitives
Implementing mutexes and condition variables requires
some kind of synchronization primitive provided by hard-
ware support that provides atomicity. Locks and con-
dition variables are higher-level abstractions over these
synchronization primitives. On a uniprocessor, disabling
and enabling interrupts is a way to implement monitors by
preventing context switches during the critical sections of
the locks and condition variables, but this is not enough
on a multiprocessor. On a multiprocessor, usually special
atomic read-modify-write instructions on the memory
such as test-and-set, compare-and-swap, etc. are used,
depending on what the ISA provides. These usually re-
quire deferring to spin-locking for the internal lock state
itself, but this locking is very brief. Depending on the im-
plementation, the atomic read-modify-write instructions
may lock the bus from other cores’ accesses and/or pre-
vent re-ordering of instructions in the CPU. Here is an ex-
ample pseudocode implementation of parts of a threading
system and mutexes and Mesa-style condition variables,
using test-and-set and a first-come, first-served policy.
This glosses over most of how a threading system works,
but shows the parts relevant to mutexes and condition
variables:
Sample Mesa-monitor implementation with Test-
and-Set // Basic parts of threading system: // Assume
“ThreadQueue” supports random access. public volatile
ThreadQueue readyQueue; // Thread-unsafe queue
of ready threads. Elements are (Thread*). public
volatile global Thread* currentThread; // Assume
this variable is per-core. (Others are shared.) // Im-
plements a spin-lock on just the synchronized state
of the threading system itself. // This is used with
test-and-set as the synchronization primitive. public
105
volatile global bool threadingSystemBusy=false; //
Context-switch interrupt service routine (ISR): // On
the current CPU core, preemptively switch to another
thread. public method contextSwitchISR(){ if (tes-
tAndSet(threadingSystemBusy)){ return; // Can't switch
context right now. } // Ensure this interrupt can't happen
again which would foul up the context switch: system-
Call_disableInterrupts(); // Get all of the registers of
the currently-running process. // For Program Counter
(PC), we will need the instruction location of // the
“resume” label below. Getting the register values is
platform-dependent and may involve // reading the
current stack frame, JMP/CALL instructions, etc. (The
details are beyond this scope.) currentThread->registers
= getAllRegisters(); // Store the registers in the “current-
Thread” object in memory. currentThread->registers.PC
= resume; // Set the next PC to the “resume” label below
in this method. readyQueue.enqueue(currentThread); //
Put this thread back onto the ready queue for later ex-
ecution. Thread* otherThread=readyQueue.dequeue();
// Remove and get the next thread to run from the
ready queue. currentThread=otherThread; // Replace
the global current-thread pointer value so it is ready
for the next thread. // Restore the registers from cur-
rentThread/otherThread, including a jump to the stored
PC of the other thread // (at “resume” below). Again,
the details of how this is done are beyond this scope.
restoreRegisters(otherThread.registers); // *** Now
running “otherThread” (which is now “currentThread”)!
The original thread is now “sleeping”. *** resume:
// This is where another contextSwitch() call needs
to set PC to when switching context back here. //
Return to where otherThread left off. threadingSys-
temBusy=false; // Must be an atomic assignment.
systemCall_enableInterrupts(); // Turn pre-emptive
switching back on on this core. } // Thread sleep
method: // On current CPU core, a synchronous context
switch to another thread without putting // the current
thread on the ready queue. // Must be holding “thread-
ingSystemBusy” and disabled interrupts so that this
method // doesn't get interrupted by the thread-switching
timer which would call contextSwitchISR(). // After
returning from this method, must clear “threadingSys-
temBusy”. public method threadSleep(){ // Get all of
the registers of the currently-running process. // For
Program Counter (PC), we will need the instruction
location of // the “resume” label below. Getting the
register values is platform-dependent and may involve
// reading the current stack frame, JMP/CALL in-
structions, etc. (The details are beyond this scope.)
currentThread->registers = getAllRegisters(); // Store
the registers in the “currentThread” object in memory.
currentThread->registers.PC = resume; // Set the next
PC to the “resume” label below in this method. // Unlike
contextSwitchISR(), we will not place currentThread
back into readyQueue. // Instead, it has already been
placed onto a mutex’s or condition variable’s queue.
Thread* otherThread=readyQueue.dequeue(); // Re-
106
move and get the next thread to run from the ready
queue. currentThread=otherThread; // Replace the
global current-thread pointer value so it is ready for
the next thread. // Restore the registers from current-
Thread/otherThread, including a jump to the stored PC
of the other thread // (at “resume” below). Again, the
details of how this is done are beyond this scope. restor-
eRegisters(otherThread.registers); // *** Now running
“otherThread” (which is now “currentThread”)! The
original thread is now “sleeping”. *** resume: // This is
where another contextSwitch() call needs to set PC to
when switching context back here. // Return to where
otherThread left off. } public method wait(Mutex m,
ConditionVariable c){ // Internal spin-lock while other
threads on any core are accessing this object’s // “held”
and “threadQueue”, or “readyQueue”. while (testAnd-
Set(threadingSystemBusy)){} // N.B.: “threadingSys-
temBusy” is now true. // System call to disable interrupts
on this core so that threadSleep() doesn't get interrupted
by // the thread-switching timer on this core which would
call contextSwitchISR(). // Done outside threadSleep()
for more efficiency so that this thread will be sleeped //
right after going on the condition-variable queue. system-
Call_disableInterrupts(); assert m.held; // (Specifically,
this thread must be the one holding it.) m.release();
c.waitingThreads.enqueue(currentThread); thread-
Sleep(); // Thread sleeps ... Thread gets woken up from a
signal/broadcast. threadingSystemBusy=false; // Must be
an atomic assignment. systemCall_enableInterrupts(); //
Turn pre-emptive switching back on on this core. // Mesa
style: // Context switches may now occur here, making
the client caller’s predicate false. m.acquire(); } public
method signal(ConditionVariable c){ // Internal spin-lock
while other threads on any core are accessing this object’s
// “held” and “threadQueue”, or “readyQueue”. while
(testAndSet(threadingSystemBusy)){} // N.B.: “thread-
ingSystemBusy” is now true. // System call to disable
interrupts on this core so that threadSleep() doesn't get
interrupted by // the thread-switching timer on this core
which would call contextSwitchISR(). // Done outside
threadSleep() for more efficiency so that this thread will
be sleeped // right after going on the condition-
variable queue. systemCall_disableInterrupts();
if (!c.waitingThreads.isEmpty()){ wo-
kenThread=c.waitingThreads.dequeue();
readyQueue.enqueue(wokenThread); } threadingSys-
temBusy=false; // Must be an atomic assignment.
systemCall_enableInterrupts(); // Turn pre-emptive
switching back on on this core. // Mesa style: // The
woken thread is not given any priority. } public method
broadcast(ConditionVariable c){ // Internal spin-lock
while other threads on any core are accessing this object’s
// “held” and “threadQueue”, or “readyQueue”. while
(testAndSet(threadingSystemBusy)){} // N.B.: “thread-
ingSystemBusy” is now true. // System call to disable
interrupts on this core so that threadSleep() doesn't get
interrupted by // the thread-switching timer on this core
which would call contextSwitchISR(). // Done outside
CHAPTER 5. CONCURRENCY PATTERNS
threadSleep() for more efficiency so that this thread will
be sleeped // right after going on the condition-
variable queue. systemCall_disableInterrupts();
while (!c.waitingThreads.isEmpty()){ wo-
kenThread=c.waitingThreads.dequeue();
readyQueue.enqueue(wokenThread); } threadingSys-
temBusy=false; // Must be an atomic assignment.
systemCall_enableInterrupts(); // Turn pre-emptive
switching back on on this core. // Mesa style: // The
woken threads are not given any priority. } class
Mutex { protected volatile bool held=false; private
volatile ThreadQueue blockingThreads; // Thread-unsafe
queue of blocked threads. Elements are (Thread*).
public method acquire(){ // Internal spin-lock while
other threads on any core are accessing this object’s
// “held” and “threadQueue”, or “readyQueue”. while
(testAndSet(threadingSystemBusy)){} // N.B.: “thread-
ingSystemBusy” is now true. // System call to disable
interrupts on this core so that threadSleep() doesn't
get interrupted by // the thread-switching timer on
this core which would call contextSwitchISR(). //
Done outside threadSleep() for more efficiency so
that this thread will be sleeped // right after going
on the lock queue. systemCall_disableInterrupts();
assert !blockingThreads.contains(currentThread); if
(held){ // Put “currentThread” on this lock’s queue so
that it will be // considered “sleeping” on this lock. //
Note that “currentThread” still needs to be handled
by threadSleep(). readyQueue.remove(currentThread);
blockingThreads.enqueue(currentThread); thread-
Sleep(); // Now we are woken up, which must be
because “held” became false. assert !held; assert
!blockingThreads.contains(currentThread); } held=true;
threadingSystemBusy=false; // Must be an atomic
assignment. systemCall_enableInterrupts(); // Turn
pre-emptive switching back on on this core. } pub-
lic method release(){ // Internal spin-lock while
other threads on any core are accessing this ob-
ject’s // “held” and “threadQueue”, or “readyQueue”.
while (testAndSet(threadingSystemBusy)){} // N.B.:
“threadingSystemBusy” is now true. // System call
to disable interrupts on this core for efficiency.
systemCall_disableInterrupts(); assert held; // (Re-
lease should only be performed while the lock is
held.) held=false; if (!blockingThreads.isEmpty()){
Thread* unblockedThread=blockingThreads.dequeue();
readyQueue.enqueue(unblockedThread); } thread-
ingSystemBusy=false; // Must be an atomic assignment.
systemCall_enableInterrupts(); // Turn pre-emptive
switching back on on this core. } } struct ConditionVa-
riable { volatile ThreadQueue waitingThreads; }
Semaphore
As an example, consider a thread-safe class that imple-
ments a semaphore. There are methods to increment (V)
and to decrement (P) a private integer s. However, the in-
5.9. MONITOR 107

teger must never be decremented below 0; thus a thread // (The semaphore’s internal state is necessarily private.)
that tries to decrement must wait until the integer is pos- protected Semaphore sem=Semaphore(0); // Provides
itive. We use a condition variable sIsPositive with an as- the wait queue. protected Mutex internalMutex; //
sociated assertion of PsIsP ositive = (s > 0) . (Really another Semaphore. Protects “numWaiters”.) }
monitor class Semaphore { private int s := 0 invariant
s >= 0 private Condition sIsPositive /* associated with s When a signal happens on a condition variable that at
> 0 */ public method P() { while s = 0: wait sIsPositive least one other thread is waiting on, there are at least two
assert s > 0 s := s - 1 } public method V() { s := s + 1 threads that could then occupy the monitor: the thread
assert s > 0 signal sIsPositive } } that signals and any one of the threads that is waiting. In
Implemented showing all synchronization (removing the order that at most one thread occupies the monitor at each
assumption of a thread-safe class and showing the mutex): time, a choice must be made. Two schools of thought
exist on how best to resolve this choice. This leads to two
class Semaphore { private volatile int s := 0 invariant kinds of condition variables which will be examined next:
s >= 0 private ConditionVariable sIsPositive /* associ-
ated with s > 0 */ private Mutex myLock /* Lock on
• Blocking condition variables give priority to a sig-
“s” */ public method P() { myLock.acquire() while s =
naled thread.
0: wait(myLock, sIsPositive) assert s > 0 s := s - 1 my-
Lock.release() } public method V() { myLock.acquire() • Nonblocking condition variables give priority to the
s := s + 1 assert s > 0 signal sIsPositive myLock.release() signaling thread.
}}

Blocking condition variables

Monitor implemented using semaphores Con- The original proposals by C. A. R. Hoare and Per Brinch
versely, locks and condition variables can also be derived Hansen were for blocking condition variables. With a
from semaphores, thus making monitors and semaphores blocking condition variable, the signaling thread must
reducible to one another: wait outside the monitor (at least) until the signaled thread
The implementation given here is incorrect. If a thread relinquishes occupancy of the monitor by either returning
calls wait() after signal() has been called it may be stuck or by again waiting on a condition variable. Monitors us-
indefinitely, since signal() increments the semaphore only ing blocking condition variables are often called Hoare-
enough times for threads already waiting. style monitors or signal-and-urgent-wait monitors.
public method wait(Mutex m, ConditionVariable c){ as-
sert m.held; c.internalMutex.acquire(); c.numWaiters++;
m.release(); // Can go before/after the neighboring
lines. c.internalMutex.release(); // Another thread
could signal here, but that’s OK because of how //
semaphores count. If c.sem’s number becomes 1,
we'll have no // waiting time. c.sem.Proberen(); //
Block on the CV. // Woken m.acquire(); // Re-acquire
the mutex. } public method signal(ConditionVariable
c){ c.internalMutex.acquire(); if (c.numWaiters >
0){ c.numWaiters--; c.sem.Verhogen(); // (Doesn't
need to be protected by c.internalMutex.) }
c.internalMutex.release(); } public method broad-
cast(ConditionVariable c){ c.internalMutex.acquire();
while (c.numWaiters > 0){ c.numWaiters--;
c.sem.Verhogen(); // (Doesn't need to be protected
by c.internalMutex.) } c.internalMutex.release(); }
class Mutex { protected boolean held=false; // For
assertions only, to make sure sem’s number never goes
> 1. protected Semaphore sem=Semaphore(1); // The
number shall always be at most 1. // Not held <--> 1; A Hoare style monitor with two condition variables a and b. After
held <--> 0. public method acquire(){ sem.Proberen(); Buhr et al.
assert !held; held=true; } public method release(){ assert
held; // Make sure we never Verhogen sem above 1. We assume there are two queues of threads associated
That would be bad. held=false; sem.Verhogen(); } } with each monitor object
class ConditionVariable { protected int numWaiters=0;
// Roughly tracks the number of waiters blocked in sem. • e is the entrance queue
108 CHAPTER 5. CONCURRENCY PATTERNS

• s is a queue of threads that have signaled. of the monitor postcondition P and I signal c : precon-
dition P and I modifies the state of the monitor post-
In addition we assume that for each condition variable c, condition I signal c and return : precondition P and
there is a queue I
In these contracts, it is assumed that I and P do not de-
• c.q, which is a queue for threads waiting on condi- pend on the contents or lengths of any queues.
tion variable c
(When the condition variable can be queried as to the
All queues are typically guaranteed to be fair and, in some number of threads waiting on its queue, more sophisti-
implementations, may be guaranteed to be first in first cated contracts can be given. For example, a useful pair
out. of contracts, allowing occupancy to be passed without es-
tablishing the invariant, is
The implementation of each operation is as follows. (We
assume that each operation runs in mutual exclusion to wait c : precondition I modifies the state of the monitor
the others; thus restarted threads do not begin executing postcondition P signal c precondition (not empty(c)
until the operation is complete.) and P ) or (empty(c) and I) modifies the state of the
monitor postcondition I
enter the monitor: enter the method if the monitor is [4] [5]
locked add this thread to e block this thread else lock See Howard and Buhr et al., for more).
the monitor leave the monitor: schedule return from the It is important to note here that the assertion P is entirely
method wait c : add this thread to c.q schedule block this up to the programmer; he or she simply needs to be con-
thread signal c : if there is a thread waiting on c.q select sistent about what it is.
and remove one such thread t from c.q (t is called “the
We conclude this section with an example of a thread-
signaled thread”) add this thread to s restart t (so t will
safe class using a blocking monitor that implements a
occupy the monitor next) block this thread schedule : if
bounded, thread-safe stack.
there is a thread on s select and remove one thread from
s and restart it (this thread will occupy the monitor next) monitor class SharedStack { private const capacity :=
else if there is a thread on e select and remove one thread 10 private int[capacity] A private int size := 0 invari-
from e and restart it (this thread will occupy the monitor ant 0 <= size and size <= capacity private BlockingCon-
next) else unlock the monitor (the monitor will become dition theStackIsNotEmpty /* associated with 0 < size
unoccupied) and size <= capacity */ private BlockingCondition theS-
tackIsNotFull /* associated with 0 <= size and size <
The schedule routine selects the next thread to occupy
capacity */ public method push(int value) { if size = ca-
the monitor or, in the absence of any candidate threads,
pacity then wait theStackIsNotFull assert 0 <= size and
unlocks the monitor.
size < capacity A[size] := value ; size := size + 1 assert 0
The resulting signaling discipline is known a “signal and < size and size <= capacity signal theStackIsNotEmpty
urgent wait,” as the signaler must wait, but is given prior- and return } public method int pop() { if size = 0 then
ity over threads on the entrance queue. An alternative is wait theStackIsNotEmpty assert 0 < size and size <=
“signal and wait,” in which there is no s queue and signaler capacity size := size - 1 ; assert 0 <= size and size <
waits on the e queue instead. capacity signal theStackIsNotFull and return A[size] }
Some implementations provide a signal and return op- }
eration that combines signaling with returning from a pro- Note that, in this example, the thread-safe stack is in-
cedure. ternally providing a mutex, which, as in the earlier pro-
signal c and return : if there is a thread waiting on c.q ducer/consumer example, is shared by both condition
select and remove one such thread t from c.q (t is called variables, which are checking different conditions on the
“the signaled thread”) restart t (so t will occupy the mon- same concurrent data. The only difference is that the pro-
itor next) else schedule return from the method ducer/consumer example assumed a regular non-thread-
safe queue and was using a standalone mutex and con-
In either case (“signal and urgent wait” or “signal and dition variables, without these details of the monitor ab-
wait”), when a condition variable is signaled and there is stracted away as is the case here. In this example, when
at least one thread on waiting on the condition variable, the “wait” operation is called, it must somehow be sup-
the signaling thread hands occupancy over to the signaled plied with the thread-safe stack’s mutex, such as if the
thread seamlessly, so that no other thread can gain occu- “wait” operation is an integrated part of the “monitor
pancy in between. If P is true at the start of each signal class”. Aside from this kind of abstracted functionality,
c operation, it will be true at the end of each wait c oper- when a “raw” monitor is used, it will always have to in-
ation. This is summarized by the following contracts. In clude a mutex and a condition variable, with a unique mu-
these contracts, I is the monitor’s invariant. tex for each condition variable.
enter the monitor: postcondition I leave the monitor:
precondition I wait c : precondition I modifies the state
5.9. MONITOR 109

Nonblocking condition variables Howard[4] and Buhr et al.[5] for further discussion.
It is possible to associate an assertion P with each condi-
With nonblocking condition variables (also called “Mesa tion variable c such that P is sure to be true upon return
style” condition variables or “signal and continue” con- from wait c. However, one must ensure that P is pre-
dition variables), signaling does not cause the signaling served from the time the notifying thread gives up occu-
thread to lose occupancy of the monitor. Instead the sig- pancy until the notified thread is selected to re-enter the
naled threads are moved to the e queue. There is no need monitor. Between these times there could be activity by
for the s queue. other occupants. Thus it is common for P to simply be
true.
For this reason, it is usually necessary to enclose each
wait operation in a loop like this
while not( P ) do wait c
where P is some condition stronger than P . The opera-
tions notify c and notify all c are treated as “hints” that
P may be true for some waiting thread. Every iteration
of such a loop past the first represents a lost notification;
thus with nonblocking monitors, one must be careful to
ensure that too many notifications can not be lost.
As an example of “hinting” consider a bank account in
which a withdrawing thread will wait until the account
has sufficient funds before proceeding
monitor class Account { private int balance := 0 invari-
ant balance >= 0 private NonblockingCondition balance-
MayBeBigEnough public method withdraw(int amount)
precondition amount >= 0 { while balance < amount
do wait balanceMayBeBigEnough assert balance >=
amount balance := balance - amount } public method
deposit(int amount) precondition amount >= 0 { balance
:= balance + amount notify all balanceMayBeBigEnough
}}
In this example, the condition being waited for is a func-
A Mesa style monitor with two condition variables a and b tion of the amount to be withdrawn, so it is impossible
for a depositing thread to know that it made such a condi-
With nonblocking condition variables, the signal opera- tion true. It makes sense in this case to allow each waiting
tion is often called notify — a terminology we will follow thread into the monitor (one at a time) to check if its as-
here. It is also common to provide a notify all operation sertion is true.
that moves all threads waiting on a condition variable to
the e queue. Implicit condition variable monitors
The meaning of various operations are given here. (We
assume that each operation runs in mutual exclusion to In the Java language, each object may be used as a moni-
the others; thus restarted threads do not begin executing tor. Methods requiring mutual exclusion must be explic-
until the operation is complete.) itly marked with the synchronized keyword. Blocks of
code may also be marked by synchronized.
enter the monitor: enter the method if the monitor is
locked add this thread to e block this thread else lock Rather than having explicit condition variables, each
the monitor leave the monitor: schedule return from the monitor (i.e. object) is equipped with a single wait queue
method wait c : add this thread to c.q schedule block this in addition to its entrance queue. All waiting is done on
thread notify c : if there is a thread waiting on c.q select this single wait queue and all notify and notifyAll opera-
and remove one thread t from c.q (t is called “the notified tions apply to this queue. This approach has been adopted
thread”) move t to e notify all c : move all threads wait- in other languages, for example C#.
ing on c.q to e schedule : if there is a thread on e select
and remove one thread from e and restart it else unlock
Implicit signaling
the monitor
As a variation on this scheme, the notified thread may be Another approach to signaling is to omit the signal opera-
moved to a queue called w, which has priority over e. See tion. Whenever a thread leaves the monitor (by returning
110 CHAPTER 5. CONCURRENCY PATTERNS

• C# (and other languages that use the .NET Frame-

work)

• Concurrent Euclid

• Concurrent Pascal

• D

• Delphi (Delphi 2009 and above, via TOb-

ject.Monitor)

• Java (via the wait and notify methods)

• Mesa

• Modula-3

• Python (via threading.Condition object)

• Ruby

• Squeak Smalltalk

• Turing, Turing+, and Object-Oriented Turing

• µC++

A number of libraries have been written that allow mon-

itors to be constructed in languages that do not support
them natively. When library calls are used, it is up to the
programmer to explicitly mark the start and end of code
A Java style monitor executed with mutual exclusion. Pthreads is one such li-
brary.

or waiting) the assertions of all waiting threads are evalu-

ated until one is found to be true. In such a system, con- 5.9.4 See also
dition variables are not needed, but the assertions must
be explicitly coded. The contract for wait is • Mutual exclusion
wait P: precondition I modifies the state of the monitor • Communicating sequential processes - a later devel-
postcondition P and I opment of monitors by C. A. R. Hoare

• Semaphore (programming)
5.9.3 History
Brinch Hansen and Hoare developed the monitor con- 5.9.5 Notes
cept in the early 1970s, based on earlier ideas of their
own and of Edsger Dijkstra.[6] Brinch Hansen published [1] Brinch Hansen, Per (1973). “7.2 Class Concept”.
the first monitor notation, adopting the class concept Operating System Principles (PDF). Prentice Hall. ISBN
of Simula 67,[1] and invented a queueing mechanism.[7] 0-13-637843-9.
Hoare refined the rules of process resumption.[2] Brinch
[2] Hoare, C. A. R. (October 1974). “Monitors: an operating
Hansen created the first implementation of monitors, in system structuring concept”. Comm. ACM. 17 (10): 549–
Concurrent Pascal.[6] Hoare demonstrated their equiva- 557. doi:10.1145/355620.361161.
lence to semaphores.
[3] Hansen, P. B. (June 1975). “The programming language
Monitors (and Concurrent Pascal) were soon used to Concurrent Pascal”. IEEE Trans. Softw. Eng. SE–1 (2):
structure process synchronization in the Solo operating 199–207. doi:10.1109/TSE.1975.6312840.
system.[8][9]
[4] Howard, John H. (1976). “Signaling in monitors”. ICSE
Programming languages that have supported monitors in- '76 Proceedings of the 2nd international conference on
clude Software engineering. International Conference on Soft-
ware Engineering. Los Alamitos, CA, USA: IEEE Com-
• Ada since Ada 95 (as protected objects) puter Society Press. pp. 47–52.
5.10. REACTOR PATTERN 111

[5] Buhr, Peter A.; Fortier, Michel; Coffin, Michael H. • Wefts::Condition Class Reference
(March 1995). “Monitor classification”. ACM Computing
Surveys. 27 (1): 63–107. doi:10.1145/214037.214100. • ACE_Condition Class Template Reference

[6] Hansen, Per Brinch (1993). “Monitors and concur- • QWaitCondition Class Reference
rent Pascal: a personal history”. HOPL-II: The sec-
ond ACM SIGPLAN conference on History of pro- • Common C++ Conditional Class Reference
gramming languages. History of Programming Lan-
guages. New York, NY, USA: ACM. pp. 1–35. • at::ConditionalMutex Class Reference
doi:10.1145/155360.155361. ISBN 0-89791-570-4.
• threads::shared – Perl extension for sharing data
[7] Brinch Hansen, Per (July 1972). “Structured multipro- structures between threads
gramming (Invited Paper)". Communications of the ACM.
• http://msdn.microsoft.com/en-us/library/
[8] Brinch Hansen, Per (April 1976). “The Solo operating ms682052(VS.85).aspx
system: a Concurrent Pascal program” (PDF). Software—
Practice and Experience. • Monitors in Visual Prolog.
[9] Brinch Hansen, Per (1977). The Architecture of Concur-
rent Programs. Prentice Hall. ISBN 0-13-044628-9.
5.10 Reactor pattern
5.9.6 Further reading The reactor design pattern is an event handling pattern for
handling service requests delivered concurrently to a ser-
• Monitors: an operating system structuring concept, vice handler by one or more inputs. The service handler
C. A. R. Hoare – Communications of the ACM, then demultiplexes the incoming requests and dispatches
v.17 n.10, p. 549-557, Oct. 1974 them synchronously to the associated request handlers.[1]
• Monitor classification P.A. Buhr, M. Fortier, M.H.
Coffin – ACM Computing Surveys, 1995
5.10.1 Structure
• Resources: Any resource that can provide input to
5.9.7 External links
or consume output from the system.
• Java Monitors (lucid explanation) • Synchronous Event Demultiplexer: Uses an event
• "Monitors: An Operating System Structuring Con- loop to block on all resources. When it is possible to
cept" by C. A. R. Hoare start a synchronous operation on a resource without
blocking, the demultiplexer sends the resource to the
• "Signalling in Monitors" by John H. Howard (com- dispatcher.
puter scientist)
• Dispatcher: Handles registering and unregistering
• "Proving Monitors" by John H. Howard (computer of request handlers. Dispatches resources from the
scientist) demultiplexer to the associated request handler.
• "Experience with Processes and Monitors in Mesa" • Request Handler: An application defined request
by Butler W. Lampson and David D. Redell handler and its associated resource.
• pthread_cond_wait – description from the Open
Group Base Specifications Issue 6, IEEE Std 1003.1 5.10.2 Properties
• "Block on a Condition Variable" by Dave Marshall
(computer scientist) All reactor systems are single threaded by definition, but
can exist in a multithreaded environment.
• "Strategies for Implementing POSIX Condition
Variables on Win32" by Douglas C. Schmidt and
Irfan Pyarali Benefits

• Condition Variable Routines from the Apache The reactor pattern completely separates application spe-
Portable Runtime Library cific code from the reactor implementation, which means
that application components can be divided into modu-
• wxCondition description lar, reusable parts. Also, due to the synchronous calling
• Boost Condition Variables Reference of request handlers, the reactor pattern allows for simple
coarse-grain concurrency while not adding the complex-
• ZThread Condition Class Reference ity of multiple threads to the system.
112
Limitations
The reactor pattern can be more difficult to debug[2] than control access to a data structure in memory that cannot
a procedural pattern due to the inverted flow of control. be updated atomically and is invalid (and should not be
Also, by only calling request handlers synchronously, the read by another thread) until the update is complete.
reactor pattern limits maximum concurrency, especially
on Symmetric multiprocessing hardware. The scalability
of the reactor pattern is limited not only by calling request
handlers synchronously, but also by the demultiplexer. [3]
5.10.3 See also Some RW locks allow the lock to be atomically upgraded
from being locked in read-mode to write-mode, as well
• Proactor pattern (a pattern that also demultiplexes
as being downgraded from write-mode to read-mode.
and dispatches events, but asynchronously)
• Application server
• C10k problem
5.10.4 References
[1] Schmidt, Douglas et al. Pattern-Oriented Software Archi-
tecture Volume 2: Patterns for Concurrent and Networked
Objects. Volume 2. Wiley, 2000.
[2] Schmidt, Douglas C., An Object Behavioral Pattern for
Demultiplexing and Dispatching Handles for Synchronous
Events (PDF)
[3] Kegel, Dan, The C10K problem, retrieved 2007-07-28
5.10.5 External links
• An Object Behavioral Pattern for Demultiplexing
and Dispatching Handles for Synchronous Events by
Douglas C. Schmidt
• APR Networking & the Reactor Pattern
• Architecture of a Highly Scalable NIO-Based Server
• Akka’s I/O Layer Architecture
5.11 Readers-writer lock
For the psychological difficulty sometimes encountered
by writers, see Writer’s block.
In computer science, a readers–writer (RW) or
shared-exclusive lock (also known as a multiple
readers/single-writer lock[1] or multi-reader lock[2] ) is
a synchronization primitive that solves one of the readers–
writers problems. An RW lock allows concurrent access
for read-only operations, while write operations require
exclusive access. This means that multiple threads can
read the data in parallel but an exclusive lock is needed
for writing or modifying data. When a writer is writing
CHAPTER 5. CONCURRENCY PATTERNS
the data, all other writers or readers will be blocked until
the writer is finished writing. A common use might be to
Readers–writer locks are usually constructed on top of
mutexes and condition variables, or on top of semaphores.
5.11.1 Upgradable RW lock
5.11.2 Priority policies
RW locks can be designed with different priority policies
for reader vs. writer access. The lock can either be de-
signed to always give priority to readers (read-preferring),
to always give priority to writers (write-preferring) or be
unspecified with regards to priority. These policies lead
to different tradeoffs with regards to concurrency and
starvation.
• Read-preferring RW locks allow for maximum con-
currency, but can lead to write-starvation if con-
tention is high. This is because writer threads will
not be able to acquire the lock as long as at least
one reading thread holds it. Since multiple reader
threads may hold the lock at once, this means that
a writer thread may continue waiting for the lock
while new reader threads are able to acquire the lock,
even to the point where the writer may still be wait-
ing after all of the readers which were holding the
lock when it first attempted to acquire it have re-
leased the lock. Priority to readers may be weak,
as just described, or strong, meaning that whenever
a writer releases the lock, any blocking readers al-
ways acquire it next.[3]:76
• Write-preferring RW locks avoid the problem of
writer starvation by preventing any new readers from
acquiring the lock if there is a writer queued and
waiting for the lock; the writer will acquire the lock
as soon as all readers which were already holding
the lock have completed.[4] The downside is that
write-preferring locks allows for less concurrency in
the presence of writer threads, compared to read-
preferring RW locks. Also the lock is less perfor-
mant because each operation, taking or releasing the
lock for either read or write, is more complex, in-
ternally requiring taking and releasing two mutexes
instead of one. This variation is sometimes also
known as “write-biased” readers–writer lock.[5]
• Unspecified priority RW locks does not provide any
guarantees with regards read vs. write access. Un-
5.11. READERS-WRITER LOCK 113

specified priority can in some situations be prefer- • Input: mutex m, condition variable c, integer r
able if it allows for a more efficient implementation. (number of readers waiting), flag w (writer waiting).
• Lock m (blocking).
5.11.3 Implementation • While w:
Several implementation strategies for readers–writer • wait c, m[lower-alpha 1]
locks exist, reducing them to synchronization primitives
that are assumed to pre-exist. • Increment r.
• Unlock m.
Using two mutexes
The lock-for-write operation is similar, but slightly dif-
[6][7][8]
Raynal demonstrates how to implement an R/W lock ferent (inputs are the same as for lock-for-read):
using two mutexes and a single integer counter. The
counter, b, tracks the number of blocking readers. One • Lock m (blocking).
mutex, r, protects b and is only used by readers; the other,
• While (w or r > 0):
g (for “global”) ensures mutual exclusion of writers. This
requires that a mutex acquired by one thread can be re- • wait c, m
leased by another. The following is pseudocode for the
operations: • Set w to true.

Begin Read • Unlock m.

• Lock r. Each of lock-for-read and lock-for-write has its own in-

verse operation. Releasing a read lock is done by decre-
• Increment b. menting r and signalling c if r has become zero (both
• If b = 1, lock g. while holding m), so that one of the threads waiting on c
can wake up and lock the R/W lock. Releasing the write
• Unlock r. lock means setting w to false and broadcasting on c (again
while holding m).[6][7][8]
End Read
5.11.4 Programming language support
• Lock r.
• Decrement b. • POSIX standard pthread_rwlock_t and associated
operations[9]
• If b = 0, unlock g.
• ReadWriteLock[10] interface and the
• Unlock r. ReentrantReadWriteLock[5] locks in Java ver-
sion 5 or above
Begin Write • Microsoft System.Threading.ReaderWriterLockSlim
lock for C# and other .NET languages[11]
• Lock g.
• std::shared_mutex read/write lock in C++14[12]
End Write • boost::shared_mutex and boost::upgrade_mutex
locks in Boost C++ Libraries[13]
• Unlock g.
• SRWLock, added to the Windows operating system
API as of Windows Vista.[14]
This implementation strategy gives weak priority to
readers.[3]:76 • sync.RWMutex in Go[15]
• Phase fair reader–writer lock, which alternates be-
Using a condition variable and a mutex tween readers and writers[16]

Alternatively, a read-preferring R/W lock can be imple-
mented in terms of a condition variable and an ordinary
(mutex) lock, in addition to an integer counter and a
boolean flag. The lock-for-read operation in this setup
is:[6][7][8]
• std::sync::RwLock read/write lock in Rust[17]
• Poco::RWLock in POCO C++ Libraries
• txrwlock.ReadersWriterDeferredLock Read-
ers/Writer Lock for Twisted[18]
114 CHAPTER 5. CONCURRENCY PATTERNS

5.11.5 Alternatives [12] “New adopted paper: N3659, Shared Locking in C++—
Howard Hinnant, Detlef Vollmann, Hans Boehm”. Stan-
The read-copy-update (RCU) algorithm is one solution to dard C++ Foundation.
the readers–writers problem. RCU is wait-free for read-
[13] Anthony Williams. “Synchronization – Boost 1.52.0”.
ers. The Linux kernel implements a special solution for Retrieved 31 Jan 2012.
few writers called seqlock.
[14] Alessandrini, Victor (2015). Shared Memory Application
Programming: Concepts and Strategies in Multicore Appli-
5.11.6 See also cation Programming. Morgan Kaufmann.

• Semaphore (programming) [15] “The Go Programming language - Package sync”. Re-

trieved 30 May 2015.
• Mutual exclusion
[16] “Reader–Writer Synchronization for Shared-Memory
• Scheduler pattern Multiprocessor Real-Time Systems” (PDF).

• Balking pattern [17] “std::sync::RwLock - Rust”. Retrieved 10 December

2015.
• File locking
[18] “Readers/Writer Lock for Twisted”. Retrieved 28
• Lock (computer science) September 2016.

5.11.7 Notes 5.12 Scheduler pattern

[1] This is the standard “wait” operation on condition vari-
ables, which, among other actions, releases the mutex m.
5.11.8 References
This article is about processes assignment in operating
systems. For transmission assignment in networks,
see network scheduler. For other uses, see scheduling
(disambiguation).

[1] Hamilton, Doug (21 April 1995). “Suggestions

for multiple-reader/single-writer lock?". In computing, scheduling is the method by which work
Newsgroup: comp.os.ms-windows.nt.misc. Usenet: specified by some means is assigned to resources that
hamilton.798430053@BIX.com. Retrieved 8 October complete the work. The work may be virtual compu-
2010. tation elements such as threads, processes or data flows,
which are in turn scheduled onto hardware resources such
[2] “Practical lock-freedom” by Keir Fraser 2004
as processors, network links or expansion cards.
[3] Raynal, Michel (2012). Concurrent Programming: Algo- A scheduler is what carries out the scheduling activity.
rithms, Principles, and Foundations. Springer. Schedulers are often implemented so they keep all com-
[4] Stevens, W. Richard; Rago, Stephen A. (2013). Advanced puter resources busy (as in load balancing), allow multiple
Programming in the UNIX Environment. Addison-Wesley. users to share system resources effectively, or to achieve
p. 409. a target quality of service. Scheduling is fundamental to
computation itself, and an intrinsic part of the execution
[5] java.util.concurrent.locks.ReentrantReadWriteLock Java model of a computer system; the concept of scheduling
readers–writer lock implementation offers a “fair” mode
makes it possible to have computer multitasking with a
[6] Herlihy, Maurice; Shavit, Nir (2012). The Art of Multi- single central processing unit (CPU).
processor Programming. Elsevier. pp. 184–185. A scheduler may aim at one of many goals, for exam-
[7] Nichols, Bradford; Buttlar, Dick; Farrell, Jacqueline ple, maximizing throughput (the total amount of work
(1996). PThreads Programming: A POSIX Standard for completed per time unit), minimizing response time (time
Better Multiprocessing. O'Reilly. pp. 84–89. from work becoming enabled until the first point it be-
gins execution on resources), or minimizing latency (the
[8] Butenhof, David R. (1997). Programming with POSIX
time between work becoming enabled and its subsequent
Threads. Addison-Wesley. pp. 253–266.
completion),[1] maximizing fairness (equal CPU time to
[9] “The Open Group Base Specifications Issue 6, IEEE Std each process, or more generally appropriate times accord-
1003.1, 2004 Edition: pthread_rwlock_destroy”. The ing to the priority and workload of each process). In prac-
IEEE and The Open Group. Retrieved 14 May 2011. tice, these goals often conflict (e.g. throughput versus la-
tency), thus a scheduler will implement a suitable com-
[10] java.util.concurrent.locks.ReadWriteLock
promise. Preference is given to any one of the concerns
[11] “ReaderWriteLockSlim Class (System.Threading)". Mi- mentioned above, depending upon the user’s needs and
crosoft Corporation. Retrieved 14 May 2011. objectives.
5.12. SCHEDULER PATTERN 115

In real-time environments, such as embedded systems hand, if all processes are CPU-bound, the I/O waiting
for automatic control in industry (for example robotics), queue will almost always be empty, devices will go un-
the scheduler also must ensure that processes can meet used, and again the system will be unbalanced. The sys-
deadlines; this is crucial for keeping the system stable. tem with the best performance will thus have a combina-
Scheduled tasks can also be distributed to remote devices tion of CPU-bound and I/O-bound processes. In modern
across a network and managed through an administrative operating systems, this is used to make sure that real-time
back end. processes get enough CPU time to finish their tasks.[3]
Long-term scheduling is also important in large-scale sys-
tems such as batch processing systems, computer clus-
5.12.1 Types of operating system sched- ters, supercomputers, and render farms. For example,
ulers in concurrent systems, coscheduling of interacting pro-
cesses is often required to prevent them from blocking
See also: Network scheduler, I/O scheduling, and Job due to waiting on each other. In these cases, special-
scheduler purpose job scheduler software is typically used to assist
these functions, in addition to any underlying admission
The scheduler is an operating system module that selects scheduling support in the operating system.
the next jobs to be admitted into the system and the next
process to run. Operating systems may feature up to
three distinct scheduler types: a long-term scheduler (also Medium-term scheduling The medium-term sched-
known as an admission scheduler or high-level scheduler), uler temporarily removes processes from main memory
a mid-term or medium-term scheduler, and a short-term and places them in secondary memory (such as a hard
scheduler. The names suggest the relative frequency with disk drive) or vice versa, which is commonly referred to
which their functions are performed. as “swapping out” or “swapping in” (also incorrectly as
"paging out” or “paging in”). The medium-term sched-
uler may decide to swap out a process which has not been
Process scheduler active for some time, or a process which has a low pri-
ority, or a process which is page faulting frequently, or a
The process scheduler is a part of the operating system process which is taking up a large amount of memory in
that decides which process runs at a certain point in time. order to free up main memory for other processes, swap-
It usually has the ability to pause a running process, move ping the process back in later when more memory is avail-
it to the back of the running queue and start a new pro- able, or when the process has been unblocked and is no
cess; such a scheduler is known as preemptive scheduler, longer waiting for a resource. [Stallings, 396] [Stallings,
otherwise it is a cooperative scheduler.[2] 370]
In many systems today (those that support mapping vir-
tual address space to secondary storage other than the
Long-term scheduling The long-term scheduler, or
swap file), the medium-term scheduler may actually per-
admission scheduler, decides which jobs or processes are
form the role of the long-term scheduler, by treating bina-
to be admitted to the ready queue (in main memory); that
ries as “swapped out processes” upon their execution. In
is, when an attempt is made to execute a program, its
this way, when a segment of the binary is required it can
admission to the set of currently executing processes is
be swapped in on demand, or “lazy loaded”. [Stallings,
either authorized or delayed by the long-term scheduler.
394]
Thus, this scheduler dictates what processes are to run on
a system, and the degree of concurrency to be supported
at any one time – whether many or few processes are to Short-term scheduling The short-term scheduler (also
be executed concurrently, and how the split between I/O- known as the CPU scheduler) decides which of the ready,
intensive and CPU-intensive processes is to be handled. in-memory processes is to be executed (allocated a CPU)
The long-term scheduler is responsible for controlling the after a clock interrupt, an I/O interrupt, an operating
degree of multiprogramming. system call or another form of signal. Thus the short-
In general, most processes can be described as either I/O- term scheduler makes scheduling decisions much more
bound or CPU-bound. An I/O-bound process is one that frequently than the long-term or mid-term schedulers
spends more of its time doing I/O than it spends doing – a scheduling decision will at a minimum have to be
computations. A CPU-bound process, in contrast, gen- made after every time slice, and these are very short.
erates I/O requests infrequently, using more of its time This scheduler can be preemptive, implying that it is
doing computations. It is important that a long-term capable of forcibly removing processes from a CPU
scheduler selects a good process mix of I/O-bound and when it decides to allocate that CPU to another pro-
CPU-bound processes. If all processes are I/O-bound, cess, or non-preemptive (also known as “voluntary” or
the ready queue will almost always be empty, and the “co-operative”), in which case the scheduler is unable to
short-term scheduler will have little to do. On the other “force” processes off the CPU.
116 CHAPTER 5. CONCURRENCY PATTERNS

A preemptive scheduler relies upon a programmable in- In advanced packet radio wireless networks such as
terval timer which invokes an interrupt handler that runs HSDPA (High-Speed Downlink Packet Access ) 3.5G
in kernel mode and implements the scheduling function. cellular system, channel-dependent scheduling may be
used to take advantage of channel state information. If
the channel conditions are favourable, the throughput
Dispatcher Another component that is involved in the and system spectral efficiency may be increased. In
CPU-scheduling function is the dispatcher, which is the even more advanced systems such as LTE, the schedul-
module that gives control of the CPU to the process se- ing is combined by channel-dependent packet-by-packet
lected by the short-term scheduler. It receives control in dynamic channel allocation, or by assigning OFDMA
kernel mode as the result of an interrupt or system call. multi-carriers or other frequency-domain equalization
The functions of a dispatcher involve the following: components to the users that best can utilize them.[4]

• Context switches, in which the dispatcher saves the

state (also known as context) of the process or thread First come, first serve
that was previously running; the dispatcher then
loads the initial or previously saved state of the new Main article: FIFO (computing and electronics)
process. First in, first out (FIFO), also known as first come,

• Switching to user mode. Task Queue

• Jumping to the proper location in the user program ...
to restart that program indicated by its new state.
Thread
The dispatcher should be as fast as possible, since it is Pool
invoked during every process switch. During the con- Completed Tasks
text switches, the processor is virtually idle for a frac-
...
tion of time, thus unnecessary context switches should
be avoided. The time it takes for the dispatcher to stop
one process and start another is known as the dispatch A sample thread pool (green boxes) with a queue (FIFO) of wait-
latency.[3]:155 ing tasks (blue) and a queue of completed tasks (yellow)

first served (FCFS), is the simplest scheduling algorithm.

5.12.2 Scheduling disciplines FIFO simply queues processes in the order that they ar-
rive in the ready queue. This is commonly used for a task
Scheduling disciplines are algorithms used for distribut-
queue, for example as illustrated in this section.
ing resources among parties which simultaneously and
asynchronously request them. Scheduling disciplines
are used in routers (to handle packet traffic) as well as
in operating systems (to share CPU time among both
threads and processes), disk drives (I/O scheduling),
printers (print spooler), most embedded systems, etc.
The main purposes of scheduling algorithms are to min-
imize resource starvation and to ensure fairness amongst
the parties utilizing the resources. Scheduling deals with
the problem of deciding which of the outstanding re-
quests is to be allocated resources. There are many differ-
ent scheduling algorithms. In this section, we introduce
several of them.
In packet-switched computer networks and other
statistical multiplexing, the notion of a scheduling algo-
rithm is used as an alternative to first-come first-served
queuing of data packets.
The simplest best-effort scheduling algorithms are round-
robin, fair queuing (a max-min fair scheduling algo-
rithm), proportionally fair scheduling and maximum
throughput. If differentiated or guaranteed quality of ser-
vice is offered, as opposed to best-effort communication,
weighted fair queuing may be utilized.
• Since context switches only occur upon process
termination, and no reorganization of the process
queue is required, scheduling overhead is minimal.
• Throughput can be low, because long processes can
be holding CPU, waiting the short processes for a
long time (known as convoy effect).
• No starvation, because each process gets chance to
be executed after a definite time.
• Turnaround time, waiting time and response time
depends on the order of their arrival and can be high
for the same reasons above.
• No prioritization occurs, thus this system has trouble
meeting process deadlines.
• The lack of prioritization means that as long as every
process eventually completes, there is no starvation.
In an environment where some processes might not
complete, there can be starvation.
• It is based on queuing.
5.12. SCHEDULER PATTERN
Earliest deadline first
Main article: Earliest deadline first scheduling
Earliest deadline first (EDF) or least time to go is a dy- cesses.
namic scheduling algorithm used in real-time operating
systems to place processes in a priority queue. When-
ever a scheduling event occurs (a task finishes, new task
is released, etc.), the queue will be searched for the pro-
cess closest to its deadline, which will be the next to be
scheduled for execution.
Shortest remaining time first
Main article: Shortest remaining time first
Similar to shortest job first (SJF). With this strategy the
scheduler arranges processes with the least estimated pro-
cessing time remaining to be next in the queue. This re-
quires advanced knowledge or estimations about the time
required for a process to complete.
• If a shorter process arrives during another process’ • Starvation of lower-priority processes is possible
execution, the currently running process is inter-
rupted (known as preemption), dividing that process
into two separate computing blocks. This creates
excess overhead through additional context switch-
ing. The scheduler must also place each incoming Round-robin scheduling
process into a specific place in the queue, creating
additional overhead. Main article: Round-robin scheduling
• This algorithm is designed for maximum throughput
in most scenarios.
• Waiting time and response time increase as the pro- time-slice it got terminated otherwise it is rescheduled af-
cess’s computational requirements increase. Since ter giving a chance to all other processes.
turnaround time is based on waiting time plus pro-
cessing time, longer processes are significantly af-
fected by this. Overall waiting time is smaller than
FIFO, however since no process has to wait for the
termination of the longest process.
• No particular attention is given to deadlines, the pro-
grammer can only attempt to make processes with
deadlines as short as possible.
• Starvation is possible, especially in a busy system
with many small processes being run.
• This policy is rarely used, as of 2014.
• To use this policy we should have at least two pro-
cesses of different priority
Fixed priority pre-emptive scheduling
Main article: Fixed priority pre-emptive scheduling
117
The operating system assigns a fixed priority rank to every
process, and the scheduler arranges the processes in the
ready queue in order of their priority. Lower-priority pro-
cesses get interrupted by incoming higher-priority pro-
• Overhead is not minimal, nor is it significant.
• FPPS has no particular advantage in terms of
throughput over FIFO scheduling.
• If the number of rankings is limited, it can be char-
acterized as a collection of FIFO queues, one for
each priority ranking. Processes in lower-priority
queues are selected only when all of the higher-
priority queues are empty.
• Waiting time and response time depend on the pri-
ority of the process. Higher-priority processes have
smaller waiting and response times.
• Deadlines can be met by giving processes with dead-
lines a higher priority.
with large numbers of high-priority processes queu-
ing for CPU time.
The scheduler assigns a fixed time unit per process, and
cycles through them.If process completes within that
• RR scheduling involves extensive overhead, espe-
cially with a small time unit.
• Balanced throughput between FCFS/ FIFO and
SJF/SRTF, shorter jobs are completed faster than
in FIFO and longer processes are completed faster
than in SJF.
• Good average response time, waiting time is depen-
dent on number of processes, and not average pro-
cess length.
• Because of high waiting times, deadlines are rarely
met in a pure RR system.
• Starvation can never occur, since no priority is given.
Order of time unit allocation is based upon process
arrival time, similar to FIFO.
• If Time-Slice is large It becomes FCFS /FIFO or If
it is short then it becomes SJF/SRTF.
118 CHAPTER 5. CONCURRENCY PATTERNS

Multilevel queue scheduling • May not be optimal for all applications

Main article: Multilevel queue • Effectiveness is completely dependent on the imple-

mentation

This is used for situations in which processes are easily di-

vided into different groups. For example, a common divi- Choosing a scheduling algorithm
sion is made between foreground (interactive) processes
and background (batch) processes. These two types of When designing an operating system, a programmer must
processes have different response-time requirements and consider which scheduling algorithm will perform best
so may have different scheduling needs. It is very useful for the use the system is going to see. There is no uni-
for shared memory problems. versal “best” scheduling algorithm, and many operating
systems use extended or combinations of the scheduling
algorithms above.
Work-conserving schedulers
For example, Windows NT/XP/Vista uses a multilevel
Main article: Work-conserving scheduler feedback queue, a combination of fixed-priority preemp-
tive scheduling, round-robin, and first in, first out algo-
rithms. In this system, threads can dynamically increase
A work-conserving scheduler is a scheduler that always or decrease in priority depending on if it has been ser-
tries to keep the scheduled resources busy, if there are viced already, or if it has been waiting extensively. Ev-
submitted jobs ready to be scheduled. In contrast, a non- ery priority level is represented by its own queue, with
work conserving scheduler is a scheduler that, in some round-robin scheduling among the high-priority threads
cases, may leave the scheduled resources idle despite the and FIFO among the lower-priority ones. In this sense,
presence of jobs ready to be scheduled. response time is short for most threads, and short but crit-
ical system threads get completed very quickly. Since
threads can only use one time unit of the round-robin in
Scheduling optimization problems
the highest-priority queue, starvation can be a problem
for longer high-priority threads.
There are several scheduling problems in which the goal
is to decide which job goes to which station at what time,
such that the total makespan is minimized: 5.12.3 Operating system process scheduler
implementations
• Job shop scheduling – there are n jobs and m identi-
cal stations. Each job should be executed on a single The algorithm used may be as simple as round-robin in
machine. This is usually regarded as an online prob- which each process is given equal time (for instance 1 ms,
lem. usually between 1 ms and 100 ms) in a cycling list. So,
• Open-shop scheduling – there are n jobs and m dif- process A executes for 1 ms, then process B, then process
ferent stations. Each job should spend some time at C, then back to process A.
each station, in a free order. More advanced algorithms take into account process pri-
ority, or the importance of the process. This allows some
• Flow shop scheduling – there are n jobs and m dif-
processes to use more time than other processes. The
ferent stations. Each job should spend some time at
kernel always uses whatever resources it needs to ensure
each station, in a pre-determined order.
proper functioning of the system, and so can be said to
have infinite priority. In SMP(symmetric multiprocess-
Manual scheduling ing) systems, processor affinity is considered to increase
overall system performance, even if it may cause a pro-
A very common method in embedded systems is to man- cess itself to run more slowly. This generally improves
ually schedule jobs. This can for example be done in a performance by reducing cache thrashing.
time-multiplexed fashion. Sometimes the kernel is di-
vided in three or more parts: Manual scheduling, pre-
OS/360 and successors
emptive and interrupt level. Exact methods for schedul-
ing jobs are often proprietary. IBM OS/360 was available with three different sched-
ulers. The differences were such that the variants were
• No resource starvation problems often considered three different operating systems:
• Very high predictability; allows implementation of
hard real-time systems • The Single Sequential Scheduler option, also known
as the Primary Control Program (PCP) provided se-
• Almost no overhead quential execution of a single stream of jobs.
5.12. SCHEDULER PATTERN
• The Multiple Sequential Scheduler option, known as
Multiprogramming with a Fixed Number of Tasks
(MFT) provided execution of multiple concurrent
jobs. Execution was governed by a priority which
had a default for each stream or could be requested
separately for each job. MFT version II added sub-
tasks (threads), which executed at a priority based
on that of the parent job. Each job stream defined
the maximum amount of memory which could be
used by any job in that stream.
• The Multiple Priority Schedulers option, or Multipro-
gramming with a Variable Number of Tasks (MVT),
featured subtasks from the start; each job requested
the priority and memory it required before execu-
tion.
Later virtual storage versions of MVS added a Workload
Manager feature to the scheduler, which schedules pro-
cessor resources according to an elaborate scheme de-
fined by the installation.
Windows
Very early MS-DOS and Microsoft Windows systems In AIX Version 4 there are three possible values for
were non-multitasking, and as such did not feature a thread scheduling policy:
scheduler. Windows 3.1x used a non-preemptive sched-
uler, meaning that it did not interrupt programs. It relied
on the program to end or tell the OS that it didn't need
the processor so that it could move on to another process.
This is usually called cooperative multitasking. Windows
95 introduced a rudimentary preemptive scheduler; how-
ever, for legacy support opted to let 16 bit applications
run without preemption.[5]
Windows NT-based operating systems use a multilevel
feedback queue. 32 priority levels are defined, 0 through
to 31, with priorities 0 through 15 being “normal” priori-
ties and priorities 16 through 31 being soft real-time pri-
orities, requiring privileges to assign. 0 is reserved for the
Operating System. Users can select 5 of these priorities
to assign to a running application from the Task Manager
application, or through thread management APIs. The
kernel may change the priority level of a thread depend-
ing on its I/O and CPU usage and whether it is interactive
(i.e. accepts and responds to input from humans), raising
the priority of interactive and I/O bounded processes and
lowering that of CPU bound processes, to increase the re-
[6]
sponsiveness of interactive applications. The scheduler
was modified in Windows Vista to use the cycle counter
register of modern processors to keep track of exactly Threads are primarily of interest for applications that cur-
how many CPU cycles a thread has executed, rather than rently consist of several asynchronous processes. These
just using an interval-timer interrupt routine.[7] Vista also applications might impose a lighter load on the system if
uses a priority scheduler for the I/O queue so that disk converted to a multithreaded structure.
defragmenters and other such programs do not interfere AIX 5 implements the following scheduling policies:
with foreground operations.[8]
119
Classic Mac OS and macOS
Mac OS 9 uses cooperative scheduling for threads, where
one process controls multiple cooperative threads, and
also provides preemptive scheduling for multiprocess-
ing tasks. The kernel schedules multiprocessing tasks
using a preemptive scheduling algorithm. All Process
Manager processes run within a special multiprocess-
ing task, called the “blue task”. Those processes are
scheduled cooperatively, using a round-robin schedul-
ing algorithm; a process yields control of the processor
to another process by explicitly calling a blocking func-
tion such as WaitNextEvent. Each process has its own
copy of the Thread Manager that schedules that process’s
threads cooperatively; a thread yields control of the pro-
cessor to another thread by calling YieldToAnyThread or
YieldToThread.[9]
macOS uses a multilevel feedback queue, with four prior-
ity bands for threads – normal, system high priority, ker-
nel mode only, and real-time.[10] Threads are scheduled
preemptively; macOS also supports cooperatively sched-
uled threads in its implementation of the Thread Manager
in Carbon.[9]
AIX
• First In, First Out: Once a thread with this policy is
scheduled, it runs to completion unless it is blocked,
it voluntarily yields control of the CPU, or a higher-
priority thread becomes dispatchable. Only fixed-
priority threads can have a FIFO scheduling policy.
• Round Robin: This is similar to the AIX Version 3
scheduler round-robin scheme based on 10ms time
slices. When a RR thread has control at the end of
the time slice, it moves to the tail of the queue of dis-
patchable threads of its priority. Only fixed-priority
threads can have a Round Robin scheduling policy.
• OTHER: This policy is defined by POSIX1003.4a
as implementation-defined. In AIX Version 4, this
policy is defined to be equivalent to RR, except that
it applies to threads with non-fixed priority. The re-
calculation of the running thread’s priority value at
each clock interrupt means that a thread may lose
control because its priority value has risen above that
of another dispatchable thread. This is the AIX Ver-
sion 3 behavior.
FIFO, round robin, and a fair round robin. The
120 CHAPTER 5. CONCURRENCY PATTERNS

FIFO policy has three different implementations: FIFO, The Completely Fair Scheduler (CFS) uses a well-
FIFO2, and FIFO3. The round robin policy is named studied, classic scheduling algorithm called fair queuing
SCHED_RR in AIX, and the fair round robin is called originally invented for packet networks. Fair queuing
SCHED_OTHER.[11] had been previously applied to CPU scheduling under the
name stride scheduling. The fair queuing CFS scheduler
has a scheduling complexity of O(log N), where N is the
Linux number of tasks in the runqueue. Choosing a task can be
done in constant time, but reinserting a task after it has
SCI (System Call Interface)
Linux kernel
Memory Process run requires O(log N) operations, because the run queue
I/O subsystem management management

Linux kernel
subsystem subsystem is implemented as a red-black tree.
Virtual File System
Virtual Signal
Terminals Sockets File systems memory handling The Brain Fuck Scheduler (BFS), also created by Con
Netfilter / Nftables Generic
Kolivas, is an alternative to the CFS.
discipline

block layer Paging process/thread

Network
Line

page creation &

protocols
Linux kernel replacement termination
Linux kernel I/O Scheduler
Packet Scheduler
Linux kernel
Character Network Block Page
Process
device device device cache
drivers drivers drivers
Scheduler
FreeBSD
IRQs Dispatcher

FreeBSD uses a multilevel feedback queue with priori-

A highly simplified structure of the Linux kernel, which includes
ties ranging from 0–255. 0–63 are reserved for inter-
process schedulers, I/O schedulers, and packet schedulers
rupts, 64–127 for the top half of the kernel, 128–159
for real-time user threads, 160–223 for time-shared user
threads, and 224–255 for idle user threads. Also, like
Linux 2.4 In Linux 2.4, an O(n) scheduler with a Linux, it uses the active queue setup, but it also has an
multilevel feedback queue with priority levels ranging idle queue.[14]
from 0 to 140 was used; 0–99 are reserved for real-time
tasks and 100–140 are considered nice task levels. For
real-time tasks, the time quantum for switching processes
was approximately 200 ms, and for nice tasks approxi-
mately 10 ms. The scheduler ran through the run queue of NetBSD
all ready processes, letting the highest priority processes
go first and run through their time slices, after which they NetBSD uses a multilevel feedback queue with priori-
will be placed in an expired queue. When the active ties ranging from 0–223. 0–63 are reserved for time-
queue is empty the expired queue will become the active shared threads (default, SCHED_OTHER policy), 64–
queue and vice versa. 95 for user threads which entered kernel space, 96-128
for kernel threads, 128–191 for user real-time threads
However, some enterprise Linux distributions such as
(SCHED_FIFO and SCHED_RR policies), and 192–223
SUSE Linux Enterprise Server replaced this scheduler
for software interrupts.
with a backport of the O(1) scheduler (which was main-
tained by Alan Cox in his Linux 2.4-ac Kernel series) to
the Linux 2.4 kernel used by the distribution.

Linux 2.6.0 to Linux 2.6.22 In versions 2.6.0 to
2.6.22, the kernel used an O(1) scheduler developed by
Ingo Molnar and many other kernel developers during the
Linux 2.5 development. For many kernel in time frame,
Con Kolivas developed patch sets which improved inter-
activity with this scheduler or even replaced it with his
own schedulers.
Since Linux 2.6.23 Con Kolivas’s work, most signif-
icantly his implementation of "fair scheduling" named
“Rotating Staircase Deadline”, inspired Ingo Molnár to
develop the Completely Fair Scheduler as a replacement
for the earlier O(1) scheduler, crediting Kolivas in his
announcement.[12] CFS is the first implementation of a
fair queuing process scheduler widely used in a general-
purpose operating system.[13]
Solaris
Solaris uses a multilevel feedback queue with priorities
ranging between 0 and 169. Priorities 0–59 are reserved
for time-shared threads, 60–99 for system threads, 100–
159 for real-time threads, and 160–169 for low priority
interrupts. Unlike Linux,[14] when a process is done using
its time quantum, it is given a new priority and put back
in the queue. Solaris 9 introduced two new scheduling
classes, namely fixed priority class and fair share class.
The threads with fixed priority have the same priority
range as that of the time-sharing class, but their prior-
ities are not dynamically adjusted. The fair scheduling
class uses CPU shares to prioritize threads for scheduling
decisions. CPU shares indicate the entitlement to CPU
resources. They are allocated to a set of processes, which
are collectively known as a project.[3]
5.12. SCHEDULER PATTERN 121

Summary [8]
[9] “Technical Notes”. Developer.apple.com. Retrieved
5.12.4 See also 2016-12-09.

• Activity selection problem [10] “Guides and Sample Code”. Developer.apple.com. Re-
trieved 2016-12-09.
• Aging (scheduling)
[11]
• Atropos scheduler [12] Molnár, Ingo (2007-04-13). "[patch] Modular Scheduler
Core and Completely Fair Scheduler [CFS]". linux-kernel
• Automated planning and scheduling
(Mailing list).
• Cyclic executive [13] Tong Li; Dan Baumberger; Scott Hahn. “Efficient
and Scalable Multiprocessor Fair Scheduling Using Dis-
• Dynamic priority scheduling
tributed Weighted Round-Robin” (PDF). Happyli.org.
• Foreground-background Retrieved 2016-12-09.
[14] “Comparison of Solaris, Linux, and FreeBSD Kernels”
• Interruptible operating system
(PDF). Archived from the original (PDF) on August 7,
• Least slack time scheduling 2008.

• Lottery scheduling General

• Priority inversion • Błażewicz, Jacek; Ecker, K.H.; Pesch, E.; Schmidt,

• Process states G.; Weglarz, J. (2001). Scheduling computer and
manufacturing processes (2 ed.). Berlin [u.a.]:
• Queuing Theory Springer. ISBN 3-540-41931-4.

• Rate-monotonic scheduling • Stallings, William (2004). Operating Systems Inter-

nals and Design Principles (fourth edition). Prentice
• Resource-Task Network Hall. ISBN 0-13-031999-6.
• Scheduling (production processes) • Information on the Linux 2.6 O(1)-scheduler
• Time-utility function
5.12.6 Further reading
5.12.5 References • Operating Systems: Three Easy Pieces by Remzi
H. Arpaci-Dusseau and Andrea C. Arpaci-
[1] Remzi H. Arpaci-Dusseau; Andrea C. Arpaci-Dusseau
Dusseau. Arpaci-Dusseau Books, 2014. Relevant
(January 4, 2015). “Chapter 7: Scheduling: Introduction,
chapters: Scheduling: Introduction Multi-level
Section 7.6: A New Metric: Response Time”. Operating
Systems: Three Easy Pieces (PDF). p. 6. Retrieved Febru- Feedback Queue Proportional-share Scheduling
ary 2, 2015. Multiprocessor Scheduling

[2] Paul Krzyzanowski (2014-02-19). “Process Scheduling:
Who gets to run next?". cs.rutgers.edu. Retrieved 2015-
01-11.
[3] Abraham Silberschatz, Peter Baer Galvin and Greg Gagne
(2013). Operating System Concepts. 9. John Wiley &
Sons,Inc. ISBN 978-1-118-06333-0.
[4] Guowang Miao; Jens Zander; Ki Won Sung; Ben Sli-
mane (2016). Fundamentals of Mobile Data Networks.
Cambridge University Press. ISBN 1107143217.
[5] Early Windows at the Wayback Machine (archive index)
[6] Sriram Krishnan. “A Tale of Two Schedulers Windows
NT and Windows CE”. Archived from the original on July
22, 2012.
[7] “Windows Administration: Inside the Windows Vista
Kernel: Part 1”. Technet.microsoft.com. 2016-11-14. Re-
trieved 2016-12-09.
• Brief discussion of Job Scheduling algorithms
• Understanding the Linux Kernel: Chapter 10 Pro-
cess Scheduling
• Kerneltrap: Linux kernel scheduler articles
• AIX CPU monitoring and tuning
• Josh Aas’ introduction to the Linux 2.6.8.1 CPU
scheduler implementation
• Peter Brucker, Sigrid Knust. Complexity results for
scheduling problems
• TORSCHE Scheduling Toolbox for Matlab is a tool-
box of scheduling and graph algorithms.
• A survey on cellular networks packet scheduling
• Large-scale cluster management at Google with
Borg
122 CHAPTER 5. CONCURRENCY PATTERNS

5.13 Thread pool pattern
Task Queue
...
Thread
Pool
Completed Tasks
...
A sample thread pool (green boxes) with waiting tasks (blue) and
completed tasks (yellow)
In computer programming, a thread pool is a software
design pattern for achieving concurrency of execution
in a computer program. Often also called a replicated
workers or worker-crew model,[1] a thread pool main-
tains multiple threads waiting for tasks to be allocated
for concurrent execution by the supervising program. By
maintaining a pool of threads, the model increases per-
formance and avoids latency in execution due to frequent
creation and destruction of threads for short-lived tasks.[2]
The number of available threads is tuned to the comput-
ing resources available to the program, such as parallel
processors, cores, memory, and network sockets.[3]
A common method of scheduling tasks for thread execu-
tion is a synchronized queue, known as a task queue. The
threads in the pool remove waiting tasks from the queue,
and place them into a completed task queue after com-
pletion of execution.
pool itself, distributes tasks to worker processes on differ-
ent computers, in order to increase the overall throughput.
Embarrassingly parallel problems are highly amenable to
this approach.
The number of threads may be dynamically adjusted dur-
ing the lifetime of an application based on the number of
waiting tasks. For example, a web server can add threads
if numerous web page requests come in and can remove
threads when those requests taper down. The cost of hav-
ing a larger thread pool is increased resource usage. The
algorithm used to determine when to create or destroy
threads affects the overall performance:
• Creating too many threads wastes resources and
costs time creating the unused threads.
• Destroying too many threads requires more time
later when creating them again.
• Creating threads too slowly might result in poor
client performance (long wait times).
• Destroying threads too slowly may starve other pro-
cesses of resources.
5.13.2 See also
• Object pool pattern
• Concurrency pattern
• Grand Central Dispatch

5.13.1 Performance • Parallel Extensions

The size of a thread pool is the number of threads kept • Parallelization

in reserve for executing tasks. It is usually a tunable pa-
rameter of the application, adjusted to optimize program • Server farm
performance.[4]
• Staged event-driven architecture
The primary benefit of a thread pool over creating a new
thread for each task is that thread creation and destruc-
tion overhead is restricted to the initial creation of the
5.13.3 References
pool, which may result in better performance and bet-
ter system stability. Creating and destroying a thread
[1] Garg, Rajat P. & Sharapov, Ilya Techniques for Optimizing
and its associated resources is an expensive process in Applications - High Performance Computing Prentice-Hall
terms of time. An excessive number of threads in reserve, 2002, p. 394
however, wastes memory, and context-switching between
the runnable threads invokes performance penalties. A [2] Holub, Allen (2000). Taming Java Threads. Apress. p.
socket connection to another network host, which might 209.
take many CPU cycles to drop and re-establish, can be
maintained more efficiently by associating it with a thread [3] Makofske, David B.; Donahoo, Michael J.; Calvert, Ken-
that lives over the course of more than one network trans- neth L. (2004). TCP/IP Sockets in C#: Practical Guide for
action. Programmers. Academic Press. p. 112.

Typically, a thread pool executes on a single computer. [4] Yibei Ling; Tracy Mullen; Xiaola Lin (April 2000).
However, thread pools are conceptually related to server “Analysis of optimal thread pool size”. ACM SIGOPS Op-
farms in which a master process, which might be a thread erating Systems Review. 34 (2): 42–55.
5.14. THREAD-LOCAL STORAGE 123

5.13.4 External links implying that there can be no race conditions). Threads
then only have to synchronise a final accumulation from
• "Query by Slice, Parallel Execute, and Join: A their own thread-local variable into a single, truly global
Thread Pool Pattern in Java" by Binildas C. A. variable.
• "Thread pools and work queues" by Brian Goetz Many systems impose restrictions on the size of the
thread-local memory block, in fact often rather tight lim-
• "A Method of Worker Thread Pooling" by Pradeep its. On the other hand, if a system can provide at least
Kumar Sahu a memory address (pointer) sized variable thread-local,
then this allows the use of arbitrarily sized memory blocks
• "Work Queue" by Uri Twig: C++ code demonstra- in a thread-local manner, by allocating such a memory
tion of pooled threads executing a work queue. block dynamically and storing the memory address of that
• "Windows Thread Pooling and Execution Chaining" block in the thread-local variable.

• "Smart Thread Pool" by Ami Bar

5.14.1 Windows implementation
• "Programming the Thread Pool in the .NET Frame-
work" by David Carmona The application programming interface (API) function
TlsAlloc can be used to obtain an unused TLS slot index;
• "The Thread Pool and Asynchronous Methods" by the TLS slot index will then be considered ‘used’.
Jon Skeet
The TlsGetValue and TlsSetValue functions are then used
• "Creating a Notifying Blocking Thread Pool in Java" to read and write a memory address to a thread-local vari-
by Amir Kirsh able identified by the TLS slot index. TlsSetValue only
affects the variable for the current thread. The TlsFree
• "Practical Threaded Programming with Python: function can be called to release the TLS slot index.
Thread Pools and Queues" by Noah Gift
There is a Win32 Thread Information Block for each
• "Optimizing Thread-Pool Strategies for Real-Time thread. One of the entries in this block is the thread-
CORBA" by Irfan Pyarali, Marina Spivak, Douglas local storage table for that thread.[1] TlsAlloc returns an
C. Schmidt and Ron Cytron index to this table, unique per address space, for each call.
Each thread has its own copy of the thread-local storage
• Conference Paper "Deferred cancellation. A behav- table. Hence, each thread can independently use TlsSet-
ioral pattern" by Philipp Bachmann Value(index) and obtain the specified value via TlsGet-
Value(index), because these set and look up an entry in
the thread’s own table.
5.14 Thread-local storage Apart from TlsXxx function family, Windows executa-
bles can define a section which is mapped to a different
Thread-local storage (TLS) is a computer program- page for each thread of the executing process. Unlike Tl-
ming method that uses static or global memory local to sXxx values, these pages can contain arbitrary and valid
a thread. addresses. These addresses, however, are different for
TLS is used in some places where ordinary, single- each executing thread and therefore should not be passed
threaded programs would use global variables but where to asynchronous functions (which may execute in a differ-
this would be inappropriate in multithreaded cases. An ent thread) or otherwise passed to code which assume that
example of such situations is where functions use a global a virtual address is unique within the whole process. TLS
variable to set an error condition (for example the global sections are managed using memory paging and its size
variable errno used by many functions of the C library). If is quantized to a page size (4kB on x86 machines). Such
errno were a global variable, a call of a system function on sections may only be defined inside a main executable of
one thread may overwrite the value previously set by a call a program - DLLs should not contain such sections, be-
of a system function on a different thread, possibly be- cause they are not correctly initialized when loading with
fore following code on that different thread could check LoadLibrary.
for the error condition. The solution is to have errno be
a variable that looks like it is global, but in fact exists
once per thread—i.e., it lives in thread-local storage. A 5.14.2 Pthreads implementation
second use case would be multiple threads accumulating
information into a global variable. To avoid a race condi- In the Pthreads API, memory local to a thread is desig-
tion, every access to this global variable would have to be nated with the term Thread-specific data.
protected by a mutex. Alternatively, each thread might The functions pthread_key_create and
accumulate into a thread-local variable (that, by defini- pthread_key_delete are used respectively to create
tion, cannot be read from or written to from other threads, and delete a key for thread-specific data. The type of
124 CHAPTER 5. CONCURRENCY PATTERNS

the key is explicitly left opaque and is referred to as • Solaris Studio C/C++, IBM XL C/C++,[3] GNU
pthread_key_t. This key can be seen by all threads. C,[4] Clang[5] and Intel C++ Compiler (Linux
In each thread, the key can be associated with thread- systems)[6] use the syntax:
specific data via pthread_setspecific. The data can later
be retrieved using pthread_getspecific. __thread int number;
In addition pthread_key_create can optionally accept a • Visual C++,[7] Intel C/C++ (Windows systems),[8]
destructor function that will automatically be called at C++Builder, and Digital Mars C++ use the syntax:
thread exit, if the thread-specific data is not NULL. The
destructor receives the value associated with the key as __declspec(thread) int number;
parameter so it can perform cleanup actions (close con-
nections, free memory, etc.). Even when a destructor is • C++Builder also supports the syntax:
specified, the program must still call pthread_key_delete
to free the thread-specific data at process level (the de- int __thread number;
structor only frees the data local to the thread).
It should be noted pthreads isn't the only way Unix multi- On Windows versions before Vista and Server 2008,
threaded and multi-cpu can share memory; far from __declspec(thread) works in DLLs only when those
it. i.e. MIT-SHM is an older yet capable standard. DLLs are bound to the executable, and will not work
Note pthreads has undergone many incompatible version for those loaded with LoadLibrary() (a protection fault
changes, also that (linux) libc stopped using /lib/tls/libs, or data corruption may occur).[9]
that pthreads is not “tls” and is not limited to sharing
memory between threads in a particular manner struc- Common Lisp (and maybe other dialects)
tured as a “standard tls”. Moreso that in linux gas(1) and
ld(1) have been continually modifying how pthreads gets Common Lisp provides a feature called dynamically
implemented at compile time. tls is important for libc scoped variables.
efficiency when multi-thread applications link against it
but is rarely a concern for non-OS-lib libs and apps and Dynamic variables have a binding which is private to the
should perhaps be avoided (due to rapid incompatibility invocation of a function and all of the children called by
of code). that function.
This abstraction naturally maps to thread-specific stor-
age, and Lisp implementations that provide threads do
5.14.3 Language-specific implementation this. Common Lisp has numerous standard dynamic vari-
ables, and so threads cannot be sensibly added to an im-
Apart from relying on programmers to call the appropri-
plementation of the language without these variables hav-
ate API functions, it is also possible to extend the pro-
ing thread-local semantics in dynamic binding.
gramming language to support TLS.
For instance the standard variable *print-base* deter-
mines the default radix in which integers are printed. If
C and C++ this variable is overridden, then all enclosing code will
print integers in an alternate radix:
In C11, the keyword _Thread_local is used to define
thread-local variables. The header <threads.h>, if sup- ;;; function foo and its children will print ;; in hexadeci-
ported, defines thread_local as a synonym for that key- mal: (let ((*print-base* 16)) (foo))
word. Example usage:
#include <threads.h> thread_local int foo = 0; If functions can execute concurrently on different
threads, this binding has to be properly thread-local, oth-
erwise each thread will fight over who controls a global
C++11 introduces the thread_local[2] keyword which can printing radix.
be used in the following cases

• Namespace level (global) variables D

• File static variables In D version 2, all static and global variables are thread-
local by default and are declared with syntax similar to
• Function static variables
“normal” global and static variables in other languages.
• Static member variables Global variables must be explicitly requested using the
shared keyword:
Aside from that, various C++ compiler implementations int threadLocal; // This is a thread-local variable. shared
provide specific ways to declare thread-local variables: int global; // This is a global variable shared with all
5.14. THREAD-LOCAL STORAGE 125

threads. Objective-C

In Cocoa, GNUstep, and OpenStep, each NSThread ob-

The shared keyword works both as the storage class, and
ject has a thread-local dictionary that can be accessed
as a type qualifier – shared variables are subject to some
through the thread’s threadDictionary method.
restrictions which statically enforce data integrity.[10] To
declare a “classic” global variable without these restric- NSMutableDictionary *dict = [[NSThread current-
tions, the unsafe __gshared keyword must be used:[11] Thread] threadDictionary]; dict[@"A key"] = @"Some
data";
__gshared int global; // This is a plain old global variable.

Perl
Java
In Perl threads were added late in the evolution of the
In Java, thread-local variables are implemented by the language, after a large body of extant code was already
ThreadLocal class object. ThreadLocal holds variable of present on the Comprehensive Perl Archive Network
type T, which is accessible via get/set methods. For ex- (CPAN). Thus, threads in Perl by default take their own
ample, ThreadLocal variable holding Integer value looks local storage for all variables, to minimise the impact
like this: of threads on extant non-thread-aware code. In Perl, a
thread-shared variable can be created using an attribute:
private static final ThreadLocal<Integer> myThreadLo-
calInteger = new ThreadLocal<Integer>(); use threads; use threads::shared; my $localvar; my
$sharedvar :shared;
At least for Oracle/OpenJDK, this does not use native
thread-local storage in spite of OS threads being used for
other aspects of Java threading. Instead, each Thread ob- Python
ject stores a (non-thread-safe) map of ThreadLocal ob-
jects to their values (as opposed to each ThreadLocal hav- In Python version 2.4 or later, local class in threading
ing a map of Thread objects to values and incurring a module can be used to create thread-local storage.
performance overhead).[12]
import threading mydata = threading.local() mydata.x = 1

.NET languages: C# and others

Ruby
In .NET Framework languages such as C#, static fields
can be marked with the ThreadStatic attribute: Ruby can create/access thread-local variables using []=/[]
class FooBar { [ThreadStatic] static int foo; } methods:
Thread.current[:user_id] = 1
In .NET 4.0 the System.Threading.ThreadLocal<T>
class is available for allocating and lazily loading thread-
local variables.
5.14.4 References
class FooBar { private static Sys-
tem.Threading.ThreadLocal<int> foo; } [1] Pietrek, Matt (May 2006). “Under the Hood”. MSDN.
Retrieved 6 April 2010.

Also an API is available for dynamically allocating [2] Section 3.7.2 in C++11 standard
thread-local variables.
[3] IBM XL C/C++: Thread-local storage

[4] GCC 3.3.1: Thread-Local Storage

Object Pascal
[5] Clang 2.0: release notes
In Object Pascal (Delphi) or Free Pascal the threadvar [6] Intel C++ Compiler 8.1 (linux) release notes: Thread-
reserved keyword can be used instead of 'var' to declare local Storage
variables using the thread-local storage.
[7] Visual Studio 2003: Thread extended storage-class mod-
var mydata_process: integer; threadvar my- ifier
data_threadlocal: integer;
[8] Intel C++ Compiler 10.0 (windows): Thread-local storage
126 CHAPTER 5. CONCURRENCY PATTERNS

[9] “Rules and Limitations for TLS”

[10] Alexandrescu, Andrei (July 6, 2010). “Chapter 13 - Con-

currency”. The D Programming Language. InformIT. p.
3. Retrieved January 3, 2014.

[11] Bright, Walter (May 12, 2009). “Migrating to Shared”.

dlang.org. Retrieved January 3, 2014.

[12] “How is Java’s ThreadLocal implemented under the

hood?". Stack Overflow. Stack Exchange. Retrieved 27
December 2015.

5.14.5 External links

• ELF Handling For Thread-Local Storage — Docu-
ment about an implementation in C or C++.

• ACE_TSS< TYPE > Class Template Reference

• RWTThreadLocal<Type> Class Template Docu-
mentation
• Article "Use thread-local Storage to Pass Thread
Specific Data" by Doug Doedens

• "Thread-Local Storage" by Lawrence Crowl

• Article "It’s Not Always Nice To Share" by Walter
Bright
• Practical ThreadLocal usage in Java:
http://www.captechconsulting.com/blogs/
a-persistence-pattern-using-threadlocal-and-ejb-interceptors

• GCC ""
Chapter 6

Text and image sources, contributors, and

licenses

6.1 Text
• Software design pattern Source: https://en.wikipedia.org/wiki/Software_design_pattern?oldid=769792638 Contributors: Fubar Obfusco,
Hirzel, Edward, Michael Hardy, Fred Bauder, Nixdorf, Pnm, Kku, Jizzbug, Rudyment, Wapcaplet, Graue, Zeno Gantner, TakuyaMurata,
Pcb21, MartinSpamer, Ahoerstemeier, Ronz, Julesd, Lancevortex, Halfdan, Ed Brey, Fuzheado, Greenrd, DJ Clayworth, Furrykef, Wern-
her, Bevo, PierreCaboche, Patrick McDonough, Phil Boswell, RickBeton, Robbot, Chealer, Craig Stuntz, Fredrik, Mountain, RedWolf,
Forseti, Wikibot, Jleedev, Cronian~enwiki, Tea2min, Enochlau, Lantzilla, Kevin Saff, BenFrantzDale, Msm, Curps, Jorend, Bovlb, Ferdi-
nand Pienaar, Khalid hassani, Neilc, Alexf, Quagmire, Beland, Maximaximax, Burschik, WOT, Rwmcfa1, Frau Holle, Andreas Kaufmann,
Zondor, Perey, Francois Trazzi~enwiki, RossPatterson, Leibniz, Michal Jurosz, Abelson, TheJames, Khalid, ZeroOne, S.K., JustinWick,
El C, Vinsci, Edward Z. Yang, Jonon, Cyc~enwiki, Cesar Moura, Flxmghvgvk, SpeedyGonsales, WikiLeon, Crdoconnor, Mdd, Melah
Hashamaim, Gary, Liao, Theuser, AdamBradley, Clubmarx, HenkvD, 2mcm, Egg, Mahanga, Boothy443, Mindmatrix, RHaworth, Un-
cle G, Bkkbrad, Unixer, Jeff3000, Nklatt, Stuartroebuck, GregorB, Prashanthns, Marudubshinki, Xtian~enwiki, BD2412, FreplySpang,
Grammarbot, Koavf, Adjusting, Salix alba, RyanNerd, Ltruett, Ligulem, Fred Bradstadt, Orborde, Quuxplusone, Fresheneesz, Jopincar,
Lambyuk, Chobot, Georgenaing, YurikBot, Albanaco, Wavelength, Borgx, JWB, Hairy Dude, Peter S., Hede2000, Rodasmith, Grubber,
SteveLoughran, EngineerScotty, Welsh, SAE1962, PrologFan, Dethomas, Natkeeran, Bota47, Dirk Riehle, FF2010, Cconnett, Lt-wiki-
bot, Ninly, JLaTondre, Shevonsilva, Eaefremov, Benandorsqueaks, TuukkaH, SmackBot, Vald, Pieleric, Renesis, AlecMcEachran, Nick-
Shaforostoff, Mdd4696, Mirokado, JMSwtlk, Nbarth, DHN-bot~enwiki, ACupOfCoffee, A. B., J00tel, Olff, Stevemidgley, Allan McInnes,
NoIdeaNick, Opticyclic, Cybercobra, Polonium, Ligulembot, Vina-iwbot~enwiki, Ugur Basak Bot~enwiki, Guehene, Triskell, Mamouri,
Antonielly, Edenphd, MarkSutton, Arch4ngel, Wikidrone, MTSbot~enwiki, Kvng, Amitch, Hu12, TingChong Ma, CzarB, Skorpion87,
JHP, Evoluzion~enwiki, Az1568, Courcelles, Tawkerbot2, Shabbirbhimani, Spdegabrielle, Ahy1, Errandir, JohnCD, WeggeBot, Neelix,
Mblumber, Snarpel, A876, Torrg, Tonymarston, Davhorn, Chrislk02, ThistleDew172, Gnewf, Sxilderik, Marek69, WinBot, Gioto, Luna
Santin, QuiteUnusual, Harborsparrow, Danger, Morten Johnsen, Legare, JAnDbot, BenjaminGittins, Sonicsuns, .anacondabot, Xypron,
Magioladitis, Parsecboy, VoABot II, Meredyth, Msjegan, Necklace, Azbarcea, Tonyfaull, Alexmadon, A3nm, Breandandalton, Mcavigelli,
Lelkesa, NunoAgostinho, Oicumayberight, MartinBot, Jackhwl, Stephanakib, J.delanoy, Seanhan, Jesperborgstrup, Katalaveno, McSly,
Plasticup, Tristan ph, Tiggerjay, Mistercupcake, Declanmcd, Hammersoft, VolkovBot, Tiktuk, Philip Trueman, Rponamgi, LeaveSleaves,
Amazedsaint, Fiskah~enwiki, Matthewdjb, VidGa, Billinghurst, Andy Dingley, Charliearcuri, Enviroboy, Mohansn, Coolestdude1, Mor-
mat, Skraedingie, Jamilsh, Jerryobject, Flyer22 Reborn, Treekids, PsyberS, Sfermigier, ClueBot, Stokito, Tesakoff, Redeyed Treefrog,
Gwyddgwyrdd, Stachelfisch, Janesconference, Excirial, M4gnum0n, Dmyersturnbull, Hans Adler, Mikaey, Bravegag, Bwoolf, XLinkBot,
Saiful vonair, BBL5660, Airplaneman, Eightcien, Addbot, Tgmattso, Jafeluv, DOI bot, Landon1980, Maria C Mosak, Asphatasawhale, Jo-
sevellezcaldas, MrOllie, Lost on Belmont, Bogdanmata, Haskellguy, Architectureblog, AtheWeatherman, Tassedethe, Numbo3-bot, Light-
bot, Adaniels.nl, Jarble, Luckas-bot, Yobot, TaBOT-zerem, TonyFlury, Pcap, Wonderfl, 4th-otaku, AnomieBOT, Jim1138, Galoubet, Der
Hakawati, Law, Citation bot, SlavMFM, Davhdavh, Xqbot, Gilo1969, Martnym, BluePlateSpecial, GrouchoBot, Khaderv, RibotBOT,
RabbiGregory, Pomoxis, BozzieBear, Vmlaker, Mark Renier, Sae1962, Alex.ryazantsev, Slivicon, Cannolis, Umbr, Citation bot 1, Mar-
coscata, Maggyero, CaptainPinko, I dream of horses, Jonesey95, Docsman, Ruudjah, Kimmelb, RedBot, Ibbbi, Pcwitchdr, Wo.luren,
Mean as custard, Ripchip Bot, Sandman25 again, Stryn, Primefac, Dcirovic, Amitdipsite, Realbox, ZéroBot, Bollyjeff, H3llBot, De-
monkoryu, Rcsprinter123, Kirby2010, Lylez, ClueBot NG, Alexandernolasco, Ptrb, Sudhanshuss, Satellizer, Frietjes, Helpful Pixie Bot,
BG19bot, Basamajoe, Northamerica1000, Devintseo, Thornbirda, Pratyya Ghosh, Irene31, Umlcat, Pintoch, SudhakarNimmala, Bogdan-
mionescu, Ibjacked, LibreNico, BurritoBazooka, Phamnhatkhanh, William Di Luigi, Biogeographist, Int80, Star767, Svoboman, Ramram
43210, Monkbot, Serv49, Omkarsoft, KasparBot, 1Wiki8Q5G7FviTHBac3dx8HhdNYwDVstR, Wikipedia acc0, Emiya~ruwiki, Jsg68x,
Bradarv90, Cmartin.scruthut, GreenC bot, Mohsin gujjar, Vanderjoe and Anonymous: 538
• Creational pattern Source: https://en.wikipedia.org/wiki/Creational_pattern?oldid=764013572 Contributors: Mrwojo, TakuyaMurata,
Lancevortex, Steinsky, IceKarma, Fredrik, RedWolf, Khalid hassani, Kusunose, Khalid, Rjwilmsi, Cdiggins, SmackBot, Kellen, Nbarth,
SashatoBot, Hu12, Aaronas, Magioladitis, Jacob Robertson, Saigyo, Andy Dingley, EmxBot, Acflorea, Bob1960evens, Excirial, PixelBot,
Marraco~enwiki, Addbot, Luckas-bot, Erik9bot, Sae1962, Arigoldx, Surement, Mean as custard, RjwilmsiBot, Ripchip Bot, Zoolium,
Ninad Nagwekar, BattyBot, Yungtrang, Ramram 43210, Vanderjoe and Anonymous: 36
• Abstract factory pattern Source: https://en.wikipedia.org/wiki/Abstract_factory_pattern?oldid=769076235 Contributors: The Anome,
Boleslav Bobcik, Hephaestos, TakuyaMurata, Pcb21, Ronabop, Ronz, Benno~enwiki, Dcoetzee, Jay, Hao2lian, Furrykef, Saltine, Phil
Boswell, Robbot, RedWolf, Treutwein, Tea2min, BenFrantzDale, Nkocharh, Quamaretto, Superborsuk, Int19h, Tomwalden, Klemen Koc-
jancic, Mecanismo, CanisRufus, Sietse Snel, Bobo192, Solra Bizna, Enric Naval, Flammifer, Anthony Appleyard, Www.koeberl.priv.at,

127
128 CHAPTER 6. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

RainbowOfLight, Mahanga, Joriki, Woohookitty, Tabletop, Bluemoose, GregorB, Magister Mathematicae, Fred Bradstadt, FlaBot, Thomas
Linder Puls, Chobot, Peterl, Roboto de Ajvol, YurikBot, RussBot, Michael Slone, Balkrishnatalele, Stephenb, Manop, Krzyp~enwiki, The-
Mandarin, Zixyer, Pelister, Naasking, Drable, Eaefremov, SmackBot, Oben, HalfShadow, Gilliam, Vvarkey, Ekamaloff~enwiki, DHN-
bot~enwiki, Scray, Rnapier, Cybercobra, Matt.forestpath, A5b, Daniel.Cardenas, Tobiasly, Sir Nicholas de Mimsy-Porpington, RoboD-
ick~enwiki, Edenphd, Lunavorax, Hu12, Rory O'Kane, Hetar, Dan Gluck, Jsgoupil, Tawkerbot2, Eastlaw, Dgquintas, Skittleys, JoshHol-
loway, Merutak, Epbr123, Oddity-, Bdean42, MER-C, Magioladitis, Msjegan, Wikidudeman, Twsx, Jay.233, Abednigo, Ftiercel, Gwern,
MartinBot, Jonathan Hall, R'n'B, Linuraj, YurfDog, LordAnubisBOT, Roboto1148, Vinod.pahuja, Wikieditor06, Vikasgoyal77, Quack-
Guru, Wilfried Loche, Rican7, Imdonatello, Topdeck, Magnub, Mormat, Tronster, WikiJonathanpeter, Frór, Alx359, Niceguyedc, Pointil-
list, Vghuston, Sun Creator, Bigscoop, Diaa abdelmoneim, Gurjinder.rathore, XLinkBot, Venturor, Druckles, Addbot, Msthil, Fluffernutter,
MrOllie, AndersBot, SpBot, Yobot, Yonghuster, SergejDergatsjev, Nallimbot, Piano non troppo, Materialscientist, Obersachsebot, Xqbot,
Mtasic, TechBot, Vinhphunguyen, Phresnel, RibotBOT, Shadowjams, AJCham, Sae1962, RedBot, Pikiwyn, Kallikanzarid, Rupendrad-
hillon, Rtushar, Trappist the monk, Sdillman, Minimac, EmausBot, Lukasz.gosik, GoingBatty, David.nussio, Nitinpai2000, Demonkoryu,
Reyjose, 28bot, ClueBot NG, Jdcollins13, Smithrondive, Strike Eagle, Firetinder, Edbecnel, MusikAnimal, Shakethehill, Pilode, Fylbe-
catulous, BluesLf, AutisticCatnip, Mumeriqbal786, Winstonne, Nicktmro, Matinict, Miladrahimi93, Blair.butterworth, Napstr4u, Zymut,
GregKalapos, Mfilatov, Sadegh 1990 hosseini, Bthachdev and Anonymous: 256
• Builder pattern Source: https://en.wikipedia.org/wiki/Builder_pattern?oldid=762978473 Contributors: Hephaestos, Edward, Ixfd64,
Phoe6, TakuyaMurata, Ronz, Rossami, Jay, Wik, Hao2lian, Brooklyn1, Finlay McWalter, RedWolf, Cyrius, Per Abrahamsen, HelgeHan,
BenFrantzDale, Bensaccount, Khalid hassani, Madoka, Beland, DcoetzeeBot~enwiki, Jarsyl, Umreemala, Anthony Appleyard, Sligocki,
Cbiffle, Uncle G, Coldboyqn, Shyal-b, Fred Bradstadt, FlaBot, Thomas Linder Puls, AlphaFoobar, CiaPan, YurikBot, Ssimsekler, Hairy
Dude, Shell Kinney, Vdevigere, Arichnad, Pelister, Cedar101, Betacommand, Bluebot, IAmAI, SonOfNothing, Emcmanus, Mikethegreen,
Sadads, Frap, Allan McInnes, Cybercobra, Dreadstar, Daniel.Cardenas, Geh, Beetstra, Hu12, Cmcginnis, Lathspell, Amniarix, JForget,
CmdrObot, BennyD, Pmussler, Blankfrack, Sanspeur, Ketorin, Aneeshpu, Odie5533, Mital.vora, Ezraj, JMatthews, West Brom 4ever,
MER-C, Magioladitis, Msjegan, Abednigo, Ftiercel, Marcusmax, Vinod.pahuja, Wikidicted, Bináris, JavierMC, PeaceNT, Vikasgoyal77,
VolkovBot, Satyr9, Aesopos, Rponamgi, Lramos, Trashtoy, Mormat, AlleborgoBot, Janpolowinski, Yintan, Nijelprim~enwiki, Oxy-
moron83, Neoguru12, Supersid01, Glylvyn, The Thing That Should Not Be, Mzedeler, Drmies, Pointillist, Vghuston, Alexbot, Sun Creator,
Rimian, Khmerang, XLinkBot, Salazard1, Addbot, Dyker, MrOllie, SpBot, Numbo3-bot, Sedziwoj~enwiki, Ptbotgourou, AnomieBOT,
Rubinbot, Beetny, Inmyhand77, DirlBot, Xqbot, Mtasic, RibotBOT, Sae1962, Craig Pemberton, Naaram, Jesus Escaped, MastiBot, Jeroen
De Dauw, Capt. James T. Kirk, EmausBot, Lukasz.gosik, T638403, Booler80, Nitinpai2000, Toteb5, Demonkoryu, Nafeezabrar, Lylez,
ClueBot NG, WinerFresh, Oddbodz, Strike Eagle, Controllersphere, Rh.vieira, Shakethehill, Alex.Cham, Gallas.aladdin, Ghuckabone,
Ecabiac, Abba-best, Marcocast, Fuksito, Ahmed Jolani, Nishanthan144, Sbhukar, MSRylander, KroOoze, KroOoOze, Metalktulu, Ev-
geniiKhomutsky, Hannibal.hero, Dkolegov, Herpesklaus, Leem02, Justacoder, Bthachdev and Anonymous: 193
• Factory method pattern Source: https://en.wikipedia.org/wiki/Factory_method_pattern?oldid=767698277 Contributors: Ed Poor,
TakuyaMurata, Haakon, Ronz, Jay, Hao2lian, Jeffrey Smith, Bearcat, Robbot, Fredrik, RedWolf, Hemanshu, KellyCoinGuy, Wlievens,
Hadal, Acm, BenFrantzDale, Khalid hassani, Beland, ArthurDenture, Kefka, Andreas Kaufmann, RedWordSmith, Jkl, Sesse, Will2k, Um-
reemala, BrokenSegue, Kjkolb, Gnyus, Jakew, Aisaac, Gary, Liao, Anthony Appleyard, AmunRa84, Nforbes, NTK, Blomskoe, Mahanga,
Jogla~enwiki, Esben~enwiki, FBarber, Qwertyus, JIP, Rjwilmsi, Yamamoto Ichiro, FlaBot, Alvin-cs, Chobot, Ssimsekler, Hairy Dude,
Michael Slone, Little3lue, Sasuke Sarutobi, Chaser, Petur Runolfsson, Matthew0028, Pelister, Nielses, CWenger, LeonardoRob0t, Allens,
Samwilson, That Guy, From That Show!, SmackBot, InverseHypercube, Vald, Apanait, Rajah9, Evilandi, Thumperward, Nbarth, Charles
Moss, Frap, Decltype, OnixWP, Rjmooney, Neshatian, LtPowers, Edenphd, Hu12, Dreftymac, Courcelles, Enselic, Cydebot, Jamitzky,
Juansempere, Ebrahim, JMatthews, Bouchecl, Stannered, Dmprantz, AntiVandalBot, Tormit, MER-C, Pergriffiths, .anacondabot, Andreas
Toth, Magioladitis, Msjegan, Nomad311, Cartoro, Abednigo, Gwern, MartinBot, Mjworthey, R'n'B, Ncmvocalist, Gman124, MikeEagling,
Bigboojum, MartinRinehart, Brvman, Kshivakumar, Vikasgoyal77, VolkovBot, Philip Trueman, Slaunger, Oshwah, Vipinhari, Andy Din-
gley, Jddahl, Arturs Licis, Mormat, AlleborgoBot, Lexxsoft, SieBot, Khoango, VVVBot, Matthewhaworth, Zvpunry, Duplicity, Toddst1,
Flyer22 Reborn, Faradayplank, Svick, AlanUS, Gerold Broser, RobinHood70, Jobriath, Dynamiclc, Binksternet, Lucascullen, Mhtzdt,
Pointillist, Vghuston, Excirial, Alexbot, Bender2k14, Diaa abdelmoneim, Bpssoft, BOTarate, Aprock, 9thbit, Joswig, XLinkBot, Fell-
Gleaming, Vianello, Addbot, Alquantor, Architectureblog, OrlinKolev, Tide rolls, Krano, Zch051383471952, Westcoastr13, Khmer42,
Luckas-bot, Yobot, Fraggle81, SergejDergatsjev, Nowforever~enwiki, Starsareblueandfaraway, AnomieBOT, Rubinbot, Mbunyard, Ci-
tation bot, FreeRangeFrog, Xqbot, Edward.in.Edmonton, Redroof, Mtasic, Khrom, Marco.panichi, Alainr345, Thehelpfulbot, Ain32,
Sae1962, Guentherwagner, Julianjensen, Paradrop, Sumone10154, Galestar, MichielDMN, Slhck, RjwilmsiBot, Jowa fan, DASHBot, Mat-
tbierner, EmausBot, Rolf the wolf, Leo Cavalcante, RA0808, Thadguidry, RenamedUser01302013, Tommy2010, Nunopicado, Demonko-
ryu, MauiBoyInMaltby, Donner60, Dineshkumar Ponnusamy, Reyjose, ClueBot NG, BlueTaRaKa, Frietjes, Widr, Zero4573, Alklazema,
Helpful Pixie Bot, Soufiane2011, BG19bot, Pup500, Thesquaregroot, 1typesetter, BattyBot, C5st4wr6ch, Emilhdiaz, DavidLeighEllis,
Matinict, Anurag870, Monkbot, Jcodetips, Kurousagi, Alaskanloops, Rforuupt, Anareth, Fmadd, SebNag and Anonymous: 347
• Lazy initialization Source: https://en.wikipedia.org/wiki/Lazy_initialization?oldid=772758993 Contributors: Derek Ross, Ed Poor,
Michael Hardy, RedWolf, Lumingz, Enochlau, Rheun, Quagmire, Maximaximax, Rhomboid, Anthony Appleyard, Sundar2000,
Bilbo1507, BD2412, TheIncredibleEdibleOompaLoompa, FlaBot, VKokielov, Cedar101, JLaTondre, Tackline, JonHarder, Doug Bell,
The9muse, Brittannica, Gustavo.mori, Blankfrack, Thijs!bot, Tormit, Magioladitis, Msjegan, Avisnacks, Abednigo, Gwern, Atropos235,
Bcraun, YordanGeorgiev, Alexey Luchkovsky, Jerryobject, MASQUERAID, RobinHood70, Sun Creator, Addbot, Ztyx~enwiki, Spock
lone wolf, RepeatUntil, Luckas-bot, Amirobot, Psychogears, Rubinbot, Xqbot, Mtasic, BluePlateSpecial, Phresnel, GrouchoBot, Angilly,
Dotyoyo, Sae1962, MastiBot, Michael9422, Demonkoryu, ClueBot NG, Dexp, Manohar reddy123123, Mark.knol, Loriendrew, TotalDe-
pravity, Anoop Manakkalath, Vieque, Bender the Bot, Bthachdev and Anonymous: 70
• Multiton pattern Source: https://en.wikipedia.org/wiki/Multiton_pattern?oldid=730408885 Contributors: Peak, Khalid hassani, Beland,
Pavel Vozenilek, Janaagaard, Spoon!, Qwertyus, .digamma, Wavelength, Bmord, Chris the speller, Nbarth, Dubwai, Gang65, A876,
Drealecs, Magioladitis, Destynova, Abednigo, Gwern, Steve R Barnes, Viy75, CliffHall, Addbot, MrOllie, Ettrig, Yobot, DanielcWiki,
DavidHarkness, AnomieBOT, Mtasic, FrescoBot, Sae1962, Rentzepopoulos, Galestar, Inumedia, ZéroBot, Ros Original, Ranjit.sail,
Wookietreiber, Demonkoryu, Heavenlyhash, CraigDWells and Anonymous: 50
• Object pool pattern Source: https://en.wikipedia.org/wiki/Object_pool_pattern?oldid=750409665 Contributors: Tenbaset, CesarB, An-
dreas Kaufmann, Abdull, Jkl, Purplefeltangel, Dgpop, Pearle, Arunkd13, Anthony Appleyard, Mahanga, Munificent, Marudubshinki,
YurikBot, Hairy Dude, Aaron Schulz, SmackBot, Christoofar, PJTraill, Nbarth, Audriusa, Vorburger, Hectorpal, Moala, Arch4ngel,
Noodlez84, Cydebot, Juansempere, Magioladitis, Msjegan, Swpb, Jestar jokin, Ruijoel, Vinod.pahuja, Saigyo, Qxz, SieBot, Svick, Robin-
Hood70, M4gnum0n, WikHead, Addbot, Luckas-bot, Yobot, ArthurBot, Obersachsebot, GrouchoBot, Prari, Sae1962, Trappist the monk,
Softwayer, DoctorKubla, Dexbot, Izkala, Sadegh 1990 hosseini and Anonymous: 39
6.1. TEXT 129

• Prototype pattern Source: https://en.wikipedia.org/wiki/Prototype_pattern?oldid=747050282 Contributors: Frecklefoot, Modster,

TakuyaMurata, Hofoen, Ronz, Hao2lian, Ceciop, RedWolf, BenFrantzDale, Michael Devore, Zarkonnen, Ary29, Enric Naval, Cmdrjame-
son, Liao, TheParanoidOne, Anthony Appleyard, Cheungpat, Grammarbot, Brighterorange, Gsp, FlaBot, YurikBot, Jengelh, Rsrikanth05,
TheMandarin, Victorwss~enwiki, Ragesoss, Eaefremov, Ashley thomas80, Patrickdepinguin, Colonies Chris, Can't sleep, clown will eat
me, Luís Felipe Braga, Doug Bell, Stalker314314, Hu12, Alessandro57, Lathspell, Cygon, Errandir, Pmussler, XcepticZP, Mital.vora, Car-
lif, MER-C, VladM, Magioladitis, Msjegan, Abednigo, Mokru, Ftiercel, J.delanoy, Zerokitsune, Vikasgoyal77, VolkovBot, Andy Dingley,
Arturs Licis, Mormat, AlleborgoBot, Leirith, Phe-bot, M2Ys4U, RobinHood70, Loren.wilton, Pointillist, Vghuston, Salazard1, Myst-
Bot, Albambot, Addbot, Ghettoblaster, Fyrael, PJonDevelopment, Btx40, Leszek Jańczuk, Numbo3-bot, Jianghan, Jarble, Ptbotgourou,
SergejDergatsjev, Nallimbot, Der Hakawati, Materialscientist, Citation bot, Mtasic, Catch ru, BluePlateSpecial, Io41, Sae1962, Igitur,
MastiBot, Andro164, Lukasz.gosik, WikitanvirBot, ScottyBerg, Klbrain, Demonkoryu, Lookforajit, ClueBot NG, Gfxiang, This lousy
T-shirt, Blaise170, Jcollo, AurelienLourot, Bh5k, Megazoid9000, Gotovikas, Arglbr, Zonito, Samykausar and Anonymous: 114
• Resource Acquisition Is Initialization Source: https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization?oldid=769999571
Contributors: Damian Yerrick, The Anome, Talliesin, Kku, CesarB, Furrykef, Pingveno, Wlievens, EvanED, Tea2min, ShaneKing, Ben-
FrantzDale, Smurfix, Tagishsimon, Neilc, Gadfium, Trevor MacInnis, Mecanismo, Bender235, CanisRufus, Anphanax, Spoon!, Eelis, Lec-
tonar, Echuck215, RoySmith, Runtime, RJFJR, Forderud, E=MC^2, Jonathan.Dodds, The Nameless, Qwertyus, Jwfearn, Kinu, Ligulem,
Rbonvall, Intgr, Fresheneesz, Sperxios, Kri, Poldi~enwiki, DanielKO, Kjwhitefoot, Honeyman, Lkarayan, That Guy, From That Show!,
SmackBot, Eriol Ancalagon, Karmastan, Alexvaughan, Mirokado, TimBentley, Thumperward, Fplay, Nbarth, Clements, Cybercobra,
Decltype, Alca Isilon~enwiki, Antonielly, Lim Wei Quan, Wikidrone, Mr Stephen, Jgrahn, DavidDecotigny, Arto B, Phonetagger, Fa-
talError, CRGreathouse, Torc2, DavePeixotto, Thijs!bot, Medinoc, Dougher, Magioladitis, Giles Bathgate, Abednigo, Gwern, Oysta, Re-
genspaziergang, Izno, Maghnus, Xerxesnine, Sebastian.Dietrich, Kvangend, Clitte bbt, Falcon8765, Bporopat, DonBarredora, Quietbri-
tishjim, Frosty976, Phe-bot, Siodhe, Tronic2, JL-Bot, Matonen, Guenther Brunthaler, Tulcod, Addbot, Mortense, Enerjazzer, Download,
Jarble, Yobot, AnomieBOT, Jjcolotti, Citation bot, GB fan, Wikante, FrescoBot, Sae1962, Nutate, Michael9422, Quilz, Alexey.kudinkin,
Demonkoryu, ChuispastonBot, The deprecator, ClueBot NG, Ptrb, Pibara, AgniKalpa, BG19bot, Encyclopedant, Grghosal, Tidigare up-
phovsman, SoylentPurple, Ex0du5 5utu7e, Finerrecliner, SoledadKabocha, David C Oliver, Mark viking, Captain Conundrum, Izkala,
GreenC bot, Ushkin N and Anonymous: 137
• Singleton pattern Source: https://en.wikipedia.org/wiki/Singleton_pattern?oldid=771211220 Contributors: NathanBeach, Derek Ross,
Taw, IanLewis~enwiki, Enchanter, Ray Van De Walker, Tfischer, Michael Hardy, Pnm, Ixfd64, TakuyaMurata, Miknight, Pcb21, GCarty,
LordK, Timwi, Greenrd, Hao2lian, Quoth-22, Phil Boswell, Mountain, RedWolf, Goofyheadedpunk, Ruakh, Xanzzibar, Jleedev, Tea2min,
BenFrantzDale, Zhen Lin, Khalid hassani, Python eggs, Chowbok, DocSigma, Beland, Vina, MFNickster, Srittau, Int19h, Abhi beckert,
Kate, RossPatterson, FuzzyBunny, Lulu of the Lotus-Eaters, Traxer~enwiki, Ascánder, Pavel Vozenilek, Janaagaard, MBisanz, Spoon!,
Dgpop, Func, Beachy, BrokenSegue, Anthony Appleyard, Mydaz, Jezmck, TheRealFennShysa, Rotring, Mcsee, Spikex, Marudubshinki,
Yurik, Jamie, MarSch, Drrngrvy, FlaBot, Who, Mpradeep, Quuxplusone, Mancini, Notivago, M7bot, Chobot, Peterl, YurikBot, Jeugeorge,
RobotE, Nmondal, Travisowens@hotmail.com, TheMandarin, Crasshopper, Cedar101, MrWiseGuy, Caballero1967, Sneftel, Doubleplus-
jeff, SmackBot, InverseHypercube, Jaalto, Chris the speller, Bluebot, Autarch, Silly rabbit, Bigbadman, MisterHand, Frap, Chlewbot, Dub-
wai, Luís Felipe Braga, Vina-iwbot~enwiki, Jago84, Doug Bell, Pomakis, JorisvS, Michael miceli, Aleenf1, IronGargoyle, Stwalkerster,
Beetstra, Wikidrone, Stalker314314, Bruno.schmidt, Hu12, DabMachine, Norm mit, GoCooL, Polymerbringer, Rogério Brito, Jsgoupil,
Atreys, Tawkerbot2, Hoggwild5, Qc, Pmussler, Blankfrack, Omnicog, Paulgear, Yukoba~enwiki, Khatru2, Christian75, Juansempere, Omi-
cronpersei8, Slinkp, Rider kabuto, Bytebear, Simeon H, Tartley, OrenBochman, Mentifisto, AntiVandalBot, Tormit, Hpesoj00, Voyaging,
Lordmetroid, Jan Nielsen, MER-C, Cusp98007, Rakeshnayak, VladM, Magioladitis, VoABot II, Msjegan, Appraiser, AndrewVeresov,
Tedickey, Aka042, Abednigo, McOsten, Vssun, Debashish, Gwern, MartinBot, NeoPhi, Ryan1101, Juanmaiz, Robert Illes, Jutiphan,
Clarkcox3, Ultra two, Lukebayes, Tomerfiliba, Vikasgoyal77, VolkovBot, Richard Fusion, Craigfis, Gbouzon, Jtitley, Swiftcoder, DaSjieb,
ThingXYZ, Greg searle, Letssurf, Billinghurst, Andy Dingley, Trashtoy, Riick, Turgan, Athlan~enwiki, Caefer, Ptero~enwiki, Cryp-
tophile, Mormat, SieBot, Freddy1990, Gorpik, Yjxiao, Jakesee, Ravensfire, PapaBaugh, Tarun.Varshney, SouthLake, Educres, Nitram
cero, Neoguru12, Jfromcanada, Yohanliyanage, Winterheat, WikiLaurent, Ethridgela, Asksol, Mild Bill Hiccup, NormBo, Eduardo.Farias,
RFST, Thomas Kist, Pointillist, Vghuston, Alexbot, Sun Creator, Wingbullet, Aitias, Joswig, Thinking Stone, Henklaak, DumZiBoT, Lun-
boks, XLinkBot, Mjharrison, Zuiopo, Innocenceisdeath, C. A. Russell, Alexius08, MystBot, Addbot, Ghettoblaster, Atethnekos, MrOl-
lie, Wbstory, Isfppoet, 5 albert square, Jarble, Vazde, OmveerChaudhary, Yobot, Thong10, Zwetan, Pcap, Aks.abhishek, TestEditBot,
AnomieBOT, Jim1138, Piano non troppo, Materialscientist, ArthurBot, Ravish9507, FreeRangeFrog, Cyril Wack, Mtasic, Marty.neal,
Serkan Kenar, Bestsss, PI314r, A Quest For Knowledge, Timp21337, Shadowjams, Jbcc, Sae1962, Kwiki, Paralyz3, Javito554, Maggyero,
B3t, Pinethicket, I dream of horses, Vernicht, Carlopires~enwiki, Ігор Дзюба, Robo Cop, Bnedelko, Xiluwu, Captchad, Vrenator, Diannaa,
Domeika, DARTH SIDIOUS 2, 1qaz-pl, TjBot, Mudx77, Ficklephil, EmausBot, Lukasz.gosik, Dagostinelli, Faolin42, Inumedia, ExilorX,
Serketan, Weirddemon, Tecle.samson, Ethaniel, Marti4d, KeithPinson, Demonkoryu, Jdcook72, Simpatico qa, HenriqueRocha, Trimmch,
Shi Hou, ClueBot NG, Bibhatripathi, Craxic, Pluma, Heidirose12345, Xuranium, Alex.Cham, Jobin Bennett, Richiebful, PatheticCopy-
Editor, David.moreno72, Ekamara, Enterprisey, Bogdanmionescu, Jahudgins, C5st4wr6ch, HenrikKronborgPedersen, François Robere,
Ankit amadeus, DavidLeighEllis, Matinict, Assafwo, Mtbradle, Arvindraivns, Nurieta, Idiotechie, Jcodetips, KH-1, Zymut, Kmogan17,
Peppy Paneer and Anonymous: 538
• Structural pattern Source: https://en.wikipedia.org/wiki/Structural_pattern?oldid=762627778 Contributors: RedWolf, Beland, Khalid,
TheParanoidOne, Mbloore, Rsathish, Mahanga, Ruud Koot, Jeff3000, Pi Delport, StephenWeber, Moe Epsilon, SmackBot, SashatoBot,
Hu12, Iridescent, Tawkerbot2, Siggimund, LazyEditor, Carewolf, S (usurped also), Mormat, Phoenix720, Addbot, Luckas-bot, Yobot,
LilHelpa, Locobot, Jijinjohn, Sae1962, Greedyhalibut, Jonesey95, Tom.Reding, Ripchip Bot, EmausBot, MrGrigg, Wikipedia acc0 and
Anonymous: 22
• Adapter pattern Source: https://en.wikipedia.org/wiki/Adapter_pattern?oldid=761808939 Contributors: Tarquin, Andre Engels, Ian-
Lewis~enwiki, Wapcaplet, TakuyaMurata, Pcb21, Ronz, Roger.wernersson, CatherineMunro, Mxn, Joerg Reiher~enwiki, Hao2lian, Gren-
delkhan, Samsara, RedWolf, Tea2min, BenFrantzDale, Abdull, Guanabot, Strib, Jonon, Sietse Snel, Rimshot, Spoon!, Psg5p, Alansohn,
TheParanoidOne, Anthony Appleyard, SteinbDJ, GilHamilton, Ruud Koot, Marudubshinki, Fred Bradstadt, FlaBot, Intgr, YurikBot, Eu-
doxie, KevinTeague, JonathanLivingston~enwiki, OrangeDog, Nbarth, DHN-bot~enwiki, Hardywang, EVula, Luís Felipe Braga, BryanG,
Doug Bell, Sir Nicholas de Mimsy-Porpington, Edenphd, Stalker314314, Hu12, CannonBallGuy, NE Ent, MichaelRWolf, Blytkerchan,
Ivant, Thijs!bot, JMatthews, Monkeyget, ThomasO1989, MER-C, Magioladitis, Msjegan, JamesBWatson, Abednigo, WeNDoR, Gwern,
Vikalpsingh, HughD, A4bot, Trashtoy, SieBot, BotMultichill, Stephen.mcmaster, Tuntable, ClueBot, Nnemo, Niceguyedc, Vanmaple,
Vghuston, Alexbot, M4gnum0n, Bravegag, XLinkBot, Alexius08, Addbot, MrOllie, LaaknorBot, Architectureblog, Jarble, Legobot, Yobot,
SergejDergatsjev, KamikazeBot, Synchronism, Jim1138, Wickorama, Materialscientist, Cyril Wack, Mtasic, TechBot, GrouchoBot, Ron-
slow, Giantbicycle, Maximno, Sae1962, RjwilmsiBot, PfhorSlayer, J36miles, EmausBot, RA0808, TuHan-Bot, Wikipelli, AvicBot, Wook-
130 CHAPTER 6. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

ietreiber, Demonkoryu, Anonymous2420, Jk2q3jrklse, Conditioner1, Jordanarseno, Conditioner123, Mshravan wiki, Happyser, MCSH,
Matinict, Alex Muscar, Stamptrader, PriyankaSabharwal, Vovanada, Klaus3b, Ashrwe4a, Bthachdev and Anonymous: 158
• Bridge pattern Source: https://en.wikipedia.org/wiki/Bridge_pattern?oldid=771791961 Contributors: Zundark, IanLewis~enwiki, Heron,
Mintguy, Frecklefoot, Wapcaplet, TakuyaMurata, Pcb21, Sugarfish, Mxn, Hao2lian, Phil Boswell, RedWolf, Tea2min, BenFrantzDale,
Areicher, Khalid hassani, Beland, Supadawg, S.K., Umreemala, Cmdrjameson, DCEdwards1966, Anthony Appleyard, MattGiuca, Cho-
chopk, ErikHaugen, Fred Bradstadt, Deathy, Drrngrvy, Thomas Linder Puls, Quuxplusone, YurikBot, TheMandarin, Długosz, NickelShoe,
SmackBot, Kellen, Unyoyega, ImageObserver, DHN-bot~enwiki, Frap, OrphanBot, Daydreamer302000, Luís Felipe Braga, Springnuts,
Narcelio, Albert cheng, Michael miceli, Edenphd, Lexxdark, Hu12, Iridescent, Rouven Thimm, Lathspell, Pmussler, Kazubon~enwiki,
Odie5533, Torc2, Omicronpersei8, Thijs!bot, Bytebear, GiM, Cdunn2001, MER-C, Vladimir Bosnjak, Tim.simpson, Patrick Schneider,
Magioladitis, Mikemill, Msjegan, Abednigo, Mcavigelli, Ftiercel, Mjworthey, Jimlonj, Wiki Raja, Hnc14, Wikidicted, Honestshrubber,
Andy Dingley, Topdeck, Djmckee1, Mormat, Argel1200, Faradayplank, Dddenton, Supersid01, Malaki12003, RobinHood70, ClueBot,
Vghuston, M4gnum0n, MichalKwiatkowski, Ykhwong, Ryanvolpe, Seethefellow, Rimian, Cra88y, XLinkBot, Rror, Cipherynx, Profaisal,
Addbot, Mkell85, Legobot, Luckas-bot, Yobot, Ptbotgourou, Nallimbot, Billyblind, Chimply, Obersachsebot, Mtasic, SassoBot, Alainr345,
Javier.eguiluz, Sae1962, Joke de Buhr, Usmanmyname, TjBot, EmausBot, Lukasz.gosik, Andriiko, Burns700, Lylez, Helpful Pixie Bot,
Pratyya Ghosh, Eacameron, Seanhalle, My-2-bits, Editorfun, Gronk Oz, Eahlay, M.mateeullah, Bthachdev and Anonymous: 157
• Composite pattern Source: https://en.wikipedia.org/wiki/Composite_pattern?oldid=755394959 Contributors: Hephaestos, Mrwojo,
TakuyaMurata, Ronz, Nikai, Charles Matthews, Dysprosia, Hao2lian, RedWolf, BenFrantzDale, DCrazy, Pinguin.tk~enwiki, Joyous!,
Kate, Will2k, Narcisse, Umreemala, CatharticMoment, Pearle, Kars~enwiki, Anthony Appleyard, Gaurav1146, Zoz, Fred Bradstadt,
Thomas Linder Puls, Vonkje, BradBeattie, Winnwang, FrankTobia, YurikBot, Hairy Dude, Larry laptop, J0no, Nick1915, Wainstead, Snef-
tel, Coffeeflower, SmackBot, InverseHypercube, Eskimbot, Gilliam, Gene Thomas, ImageObserver, Emufarmers, OrphanBot, Decltype,
Luís Felipe Braga, Albert cheng, Michael miceli, Edenphd, Stwalkerster, Waggers, Hu12, Lathspell, Judgesurreal777, Skapur, Thama-
raiselvan, Shabbirbhimani, Dycedarg, Pmussler, A876, Thijs!bot, Hervegirod, Harborsparrow, MikalZiane, MER-C, VoABot II, Msje-
gan, Rishichauhan, Sebras, Abednigo, Mefyl~enwiki, AdrianHesketh, MartinBot, Mike926908240680, J.delanoy, CMosher01, Darkspots,
Jeepday, Aaron Rotenberg, Trashtoy, Damien Cassou, Shivendradayal, Gkarlic, RobinHood70, The Thing That Should Not Be, Braiam,
Alexbot, M4gnum0n, Bravegag, Jogerh, Andrewtkchan, Skarebo, Vishalmamania, Ewger, Addbot, Zarcadia, MrOllie, Matěj Grabovský,
Matekm, Mik01aj, Luckas-bot, Yobot, Bunnyhop11, Ptbotgourou, Nagnatron, Chimply, Mtasic, Vinhphunguyen, Alainr345, Wkjyh, Red-
Bot, EmausBot, Lukasz.gosik, Tubalubalu, ZéroBot, Anonymous2420, Helpful Pixie Bot, AvocatoBot, Whirlium, OccultZone, Monkbot,
Zymut, Hujintao hjt, Bthachdev and Anonymous: 131
• Decorator pattern Source: https://en.wikipedia.org/wiki/Decorator_pattern?oldid=771904864 Contributors: Mjb, BryceHarrington,
TakuyaMurata, Dori, Ahoerstemeier, Ronz, Doradus, Wik, ErikStewart, Hao2lian, Itai, Jeeves, RedWolf, Tea2min, Connelly, BenFrantz-
Dale, Khalid hassani, Matt Crypto, Urhixidur, Will2k, Murtasa, Triskaideka, Ascánder, JRM, Photonique, ACiD2, Minghong, Hesperian,
Anthony Appleyard, AmunRa84, Joriki, Cruccone, Qwertyus, Grokus, WouterBot, P0per, YurikBot, RussBot, Romanc19s, RUL3R,
Cedar101, Mostapha, SmackBot, Arny, Nbarth, DHN-bot~enwiki, Rrburke, Cybercobra, Doug Bell, Edenphd, Wikidrone, Mjresin,
EdC~enwiki, Drae, Hu12, Francesco Terenzani~enwiki, Snooper77, FatalError, CmdrObot, Pmussler, Aihtdikh, XcepticZP, Odie5533,
Bob Stein - VisiBone, Wackimonki, Dantheman531, Harborsparrow, Tgwizard, MER-C, Msjegan, Abednigo, Gwern, Pharaoh of the
Wizards, Awistaiw, Servel333, Motine, Adam Zivner, Tomerfiliba, VolkovBot, A4bot, Ggenellina, J1o1h1n, Andy Dingley, Trashtoy,
SieBot, Gerel, Anakin101, Mild Bill Hiccup, ThomHehl, Vghuston, Alexbot, Bravegag, XLinkBot, Gslockwood, J.lonnee~enwiki, Addbot,
Mortense, Download, Hunting dog, Khmer42, Yobot, Eric-Wester, Jim1138, Materialscientist, Mtasic, Phresnel, GrouchoBot, FrescoBot,
Sae1962, Maggyero, RedBot, Alph Bot, EmausBot, Booler80, Pljungqv, Gasparovicm, Tashuhka, Nheirbaut, Nafeezabrar, ClueBot NG,
Wildewouter, Codysnider, Widr, Conditioner1, Yuqingalex, Manohar reddy123123, Einsub, ʘx, Umlcat, Makecat-bot, Radiodef, Sean-
halle, Nichobouma, Dineshmore, Ghinrael, João Guilherme Farias Duda, Monkbot, Mipiro, Zymut, InternetArchiveBot, Eellor, ISynpi,
Dnesteruk, Bthachdev and Anonymous: 203
• Facade pattern Source: https://en.wikipedia.org/wiki/Facade_pattern?oldid=759884239 Contributors: IanLewis~enwiki, Nate Silva,
TakuyaMurata, Hofoen, Mxn, Dysprosia, Jogloran, Hao2lian, Narcissus, PBS, RedWolf, Forseti, BenFrantzDale, Jorend, Leonard G., Red-
Crystal, Ran, Beland, Abdull, Lpenz, Scullder, Chestertan, Kwamikagami, Anthony Appleyard, Ashlux, Tony Sidaway, Nibblus, Jussist,
Mahanga, Darkmane, Xrm0, Immure, YurikBot, Wavelength, Hairy Dude, Zwobot, LeonardoRob0t, Andyluciano~enwiki, Jfalvarez, Vald,
DHN-bot~enwiki, Frap, Kaikko~enwiki, Cybercobra, Luís Felipe Braga, A5b, Arch4ngel, Frederikton, Hu12, Lathspell, Dreftymac, Dlo-
hcierekim, Owen214, CmdrObot, Arvindkumar.avinash, Thadius856, Tormit, Joe Schmedley, Deflective, Hangy, MER-C, Magioladitis,
Msjegan, Otterfan, Abednigo, Dw31415, Moggie2002, Wookie2u, Andy Dingley, Trashtoy, Fuhrmanator, COBot, Svick, ~enwiki,
RobinHood70, Dkeithmorris, Puchiko, BOTarate, XLinkBot, Wwjdcsk, Albambot, Addbot, MrOllie, M4c0~enwiki, Jarble, Luckas-bot,
Xiaoddkkwe, Nallimbot, Rubinbot, Materialscientist, Aff123a, Xqbot, Mtasic, Sae1962, B3t, RedBot, Synook, RjwilmsiBot, EmausBot,
Lukasz.gosik, Rajeevrvis, AvicBot, Demonkoryu, Khishig.s, ClueBot NG, Santihollmann, ChamithN and Anonymous: 135
• Front Controller pattern Source: https://en.wikipedia.org/wiki/Front_controller?oldid=771918758 Contributors: Kku, Bevo, Jpp,
Uzume, Andreas Kaufmann, RHaworth, Wavelength, SmackBot, Frap, Griba2010, Ludde23, Dmforcier, AlanUS, Ekerazha, Chadmyers,
MystBot, BBL5660, Dsimic, Addbot, MrOllie, Matekm, Yobot, Nperriault, FrescoBot, Sae1962, Bcosca, Jase21, Hmglasgow, EmausBot,
Angrytoast, Dewritech, Helpful Pixie Bot, Kentoshi, TheJJJunk, Userform, Prasanna143, Softzen, Bmarriner, Frank.blaauw, Jb10210,
Monkbot, Narky Blert, Ian (Wiki Ed), InternetArchiveBot, Biosunbj, Qizhongzhi and Anonymous: 39
• Flyweight pattern Source: https://en.wikipedia.org/wiki/Flyweight_pattern?oldid=770139706 Contributors: PierreAbbat, Ray Van De
Walker, Kurt Jansson, TakuyaMurata, Pcb21, Mxn, Hao2lian, Justo, RedWolf, BenFrantzDale, Beryllium, Beland, Teglsbo, Twyford, Diego
Moya, Sproul, Debajit, M7bot, Kri, Roboto de Ajvol, Zozakral~enwiki, ZacBowling, Ryanl, Naasking, Cedar101, SmackBot, Eskimbot,
Emj, DHN-bot~enwiki, SuperDuffMan, Gnp, Cgodley, Warren, Albert cheng, Ebswift, Hu12, Lathspell, Amniarix, Micah hainline, Al-
phaWiki~enwiki, Odie5533, MER-C, Msjegan, Abednigo, Blastthisinferno, Ageekymonk, Senu, CMosher01, LordAnubisBOT, Entropy,
VolkovBot, Wizgob~enwiki, The Wild Falcon, Vipinhari, Anirudhvyas010, Maxim, BigDunc, Andy Dingley, Anthonygerrard, Op12,
Henke37, Ctxppc, FroZman, Rdhettinger, RobinHood70, Night Goblin, Mdjpurdon, WestwoodMatt, Alexbot, PixelBot, Sun Creator,
Northerly Star, XLinkBot, Anticipation of a New Lover’s Arrival, The, Addbot, LaaknorBot, Luckas-bot, Yobot, Ptbotgourou, DavidHark-
ness, Rubinbot, Tshak, ArthurBot, Mtasic, Nexus26, Martnym, Sae1962, Trappist the monk, DanielBrauer, Hmglasgow, EmausBot, John
of Reading, Dennis714, Demonkoryu, Lazeroptyx, Lylez, ClueBot NG, Accelerometer, DaveLiu, Jk2q3jrklse, Helpful Pixie Bot, Lyric-
Coder, BattyBot, Mylesmcdonnell, Chase.Gilliam, Lambda Fairy, Abhi2434, Raymond.naseef, Vltsu, Hrs2, Ramram 43210, Monkbot,
CayceBalara, Zymut, Pkinsky, SolskGaer, Empatiia, Qzd, Cmthacker, Pauljohanneskraft, Markuzo, Zhaojianhua, Bthachdev, Alanjds,
Vusalalishov, Cline22 and Anonymous: 105
6.1. TEXT 131

• Proxy pattern Source: https://en.wikipedia.org/wiki/Proxy_pattern?oldid=768699301 Contributors: NathanBeach, TakuyaMurata, Jay,

Hao2lian, RedWolf, Nurg, Wlievens, Lumingz, Jthiesen, BenFrantzDale, Beland, Abdull, Rich Farmbrough, Will2k, Abelson, Shlomif,
Babomb, JeR, Fritz freiheit, TheParanoidOne, Anthony Appleyard, Fred Bradstadt, Avocado, FlaBot, Quuxplusone, P0per, Zoza-
kral~enwiki, Prickus, Cholmes75, Snaxe920, Royalguard11, Msaada, Bluebot, Nbarth, Audriusa, Edivorce, Decltype, Ebswift, Brownb2,
Edenphd, Hu12, Lathspell, Valodzka, Odie5533, Nonomy, TravisHein, MER-C, VladM, Msjegan, Rich257, Abednigo, Ftiercel, 0612,
Zolookas, Nzroller, Philip Trueman, A4bot, Jamelan, Andy Dingley, Pateeludg, Jd gordon, RobinHood70, ClueBot, PixelBot, BOTarate,
Bravegag, XLinkBot, Addbot, Lusum, SanthoshRadhakrishnan, Matekm, Luckas-bot, AnomieBOT, D3xter, Puplan, Azanin, Sae1962,
Laughmetal, EmausBot, Lukasz.gosik, Ad1976, Nunopicado, Demonkoryu, Livebreeze, Anonymous2420, ClueBot NG, Espresso1000,
LaM3a, Hofmic, Helpful Pixie Bot, Elector101, Marianobianchi, Shea.m.brennan, LokeshRavindranathan, Mangostaniko, Softzen, Cjeya-
balan, Zymut, Bobertyy, Pham Phi Long 1606, CAPTAIN RAJU, Markonator, Bthachdev and Anonymous: 127
• Behavioral pattern Source: https://en.wikipedia.org/wiki/Behavioral_pattern?oldid=757943503 Contributors: Phil Boswell, Fredrik, Red-
Wolf, Beland, Starfoxy, Khalid, PWilkinson, TheParanoidOne, Mahanga, Michael Slone, Stalker314314, Hu12, JForget, Magioladitis, Cic,
Wavell2003, Mormat, AlleborgoBot, Addbot, Luckas-bot, LilHelpa, JMS Old Al, Haeinous, Sae1962, Ripchip Bot, ChuispastonBot, Petrb
and Anonymous: 13
• Chain-of-responsibility pattern Source: https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern?oldid=763136898 Contributors:
Danny, TakuyaMurata, Ronz, Hao2lian, Khym Chanur, Bearcat, RedWolf, BenFrantzDale, Khalid hassani, Abdull, Rhomboid, Cmdrjame-
son, TheParanoidOne, JoaoRicardo, Itschris, Tabletop, Thomas Linder Puls, Roboto de Ajvol, Premil, Brian428, Frap, Vina-iwbot~enwiki,
Arch4ngel, Wikidrone, Hu12, Ermunishsodhi, Lathspell, Courcelles, Marcelo Pinto, Jokes Free4Me, Pcraven, Merutak, Thijs!bot, Ilion2,
Porqin, Seaphoto, Soubok~enwiki, MER-C, Jldupont~enwiki, Abednigo, Bin Sowparnika, Celephicus, King Lopez, Vikasgoyal77, Olbat,
TXiKiBoT, Arjunkul, Brenont, Ctxppc, AlanUS, Nomad7650, RobinHood70, Fmstephe, Rice Yao, Estevoaei, Vghuston, Alexbot, Pix-
elBot, Sun Creator, Mikaey, Bravegag, Addbot, Jhatax, MrOllie, Wbstory, Architectureblog, M4c0~enwiki, Jarble, Zyx, AnomieBOT,
DirlBot, Kinguy, Struggling wang, AboutMM, Shades97, Zaletskyy, B3t, Eknv, EmausBot, Demonkoryu, Reyjose, Lylez, ClueBot NG,
JDL440, BG19bot, Vyuschuk, Gotovikas, FoCuSandLeArN, Tnimas, Max siberian, Chris6647, Pavel ryzhov, MCEmperor, Gmamaladze,
UY Scuti, AnotherWikiOne, Varuncnitw, Bthachdev and Anonymous: 92
• Command pattern Source: https://en.wikipedia.org/wiki/Command_pattern?oldid=771226836 Contributors: Kku, TakuyaMurata,
Pcb21, Ronz, Ehn, Hao2lian, Omegatron, RedWolf, Vsync, Trevor Johns, BenFrantzDale, Jorend, Beland, Eyewax, Abdull, Kate, Mernen,
Will2k, Ascánder, Hooperbloob, HasharBot~enwiki, TheParanoidOne, Lightdarkness, Mahanga, Bluemoose, GregorB, Fred Bradstadt,
FlaBot, Exe, Bgwhite, Roboto de Ajvol, YurikBot, Dharesign, Zozakral~enwiki, Pi Delport, Zixyer, Smsiebe, Modify, John Lindquist,
Vald, IanVaughan, Gene Thomas, Chris the speller, MalafayaBot, Daydreamer302000, Nakon, Acmeacme, Warren, Doug Bell, Rijkbenik,
Michael miceli, JHunterJ, Hu12, Karuppiah, Thijs!bot, Widefox, Seaphoto, Darklilac, MER-C, Abednigo, Gwern, Mjworthey, Gmoore19,
JoaoTrindade, Pharaoh of the Wizards, DotnetCarpenter, Bipedalpedia, SJP, Ebainomugisha, Jevansen, ChesMartin, King Lopez, Vikas-
goyal77, Bennor, Scottywong, DavidBourguignon, Barry Fruitman, Mloskot, Svick, Owentaylor25, Oubless, Vghuston, Alexbot, Bravegag,
RexxS, Druckles, Addbot, Dtbullock, Evan.wondrasek, MrOllie, Numbo3-bot, Rubinbot, Dazhiruoyu, Materialscientist, LilHelpa, Xqbot,
Edward.in.Edmonton, Nathan Ra, Almabot, Thehelpfulbot, Terry.kfwong, MGA73bot, Sae1962, B3t, Orangeroof, OldCoder, EmausBot,
Crhopkins, PoundingCode, Dewritech, Demonkoryu, Elaz85, ClueBot NG, Chester Markel, Terheyden, Rahul verma india, Happyser,
Oster54, Volvens, Jensck93, Tnimas, ShyhHuaHung, Seanhalle, Ryannnnnnn, Napstr4u, Rmembrives, Jeremy Bidet and Anonymous: 148
• Interpreter pattern Source: https://en.wikipedia.org/wiki/Interpreter_pattern?oldid=752627905 Contributors: Mrwojo, Komap, Takuya-
Murata, Pcb21, Ronz, Hao2lian, Furrykef, Fredrik, RedWolf, Gwalla, BenFrantzDale, Mecanismo, TheParanoidOne, RJFJR, Ma-
hanga, MithrandirMage, Zozakral~enwiki, Cedar101, Allan McInnes, Cybercobra, Asciilifeform, Hu12, Lathspell, Lonelybug, Odie5533,
Merutak, Thijs!bot, Seaphoto, Davewho2, Magioladitis, Andypayne, Abednigo, LordAnubisBOT, TXiKiBoT, SamePaul, Andy Ding-
ley, Rogerwhitney, Jerryobject, Rosiestep, Svick, RobinHood70, L30nc1t0, Rice Yao, Vghuston, PixelBot, XLinkBot, Addbot, Jarble,
Matekm, Yobot, Xqbot, Borderj, Cmccormick8, Sae1962, Gelinp, Alph Bot, Lukasz.gosik, John of Reading, Mikhail Ryazanov, ClueBot
NG, Yuqingalex, BattyBot, Melcous, Jamesdhutton and Anonymous: 49
• Iterator pattern Source: https://en.wikipedia.org/wiki/Iterator_pattern?oldid=771692577 Contributors: Marj Tiefert, TakuyaMurata,
Ogmios~enwiki, Ronz, Greenrd, Jogloran, Hao2lian, RedWolf, BenFrantzDale, Beland, Abdull, Seffer, Leibniz, CanisRufus, Eaolson,
Lababidi, Bgwhite, Zozakral~enwiki, Cedar101, SmackBot, Bluebot, Frap, OrphanBot, Radagast83, Cybercobra, Iridescence, Brown-
HairedGirl, Albert cheng, Hu12, Winxa, Odie5533, Bytebear, Ravindra Josyula, Magioladitis, Usien6, Abednigo, Zerokitsune, Anna
Lincoln, Andy Dingley, Trashtoy, Mormat, Jerryobject, TechTony, ClueBot, Dhulme, Vghuston, Addbot, Btx40, Tomtheeditor, Matekm,
Yobot, J04n, Angilly, Ghthor, FrescoBot, Sae1962, Ayvengo21, Bnedelko, Eknv, D chivaluri, Dcirovic, ClueBot NG, KAMEDA, Akihiro,
Yuqingalex, Chmarkine, Mhitza, YiFeiBot, Kmilotxm, Zymut, Galiusk, Mfilatov, Luijar and Anonymous: 66
• Mediator pattern Source: https://en.wikipedia.org/wiki/Mediator_pattern?oldid=770072379 Contributors: Kku, TakuyaMurata, Ronz,
Crissov, Hao2lian, Furrykef, Toreau, RedWolf, BenFrantzDale, Bender235, RoyBoy, Flammifer, TheParanoidOne, Twyford, BRW,
FlaBot, Exe, YurikBot, Zozakral~enwiki, Rsrikanth05, Royalguard11, Jrockley, Bluebot, Colonies Chris, Frap, OrphanBot, Addshore,
Cybercobra, Adelesse, 16@r, Dcflyer, Hu12, Lathspell, Alaibot, Thijs!bot, Pietrodn, RobDe68, ThomasO1989, VladM, .anacondabot,
Rjnienaber, Abednigo, If R-rated movies are porn, it was porn, Mariolopes, Leafyplant, Mormat, AlleborgoBot, RobinHood70, Vghuston,
C3foncea, Addbot, Dawynn, Download, Jarble, Bayesianese, Ptbotgourou, Nagnatron, Rubinbot, Xqbot, Jebdm, Nexus26, Thehelpfulbot,
Sae1962, Ripchip Bot, Grancalavera, Balu213, Anonymous2420, ClueBot NG, Job Noorman, Brian Tomasik, Yuqingalex, Vijayekm,
Grizzly33, Alex.proca, Amit.tejwani, Galhalee, JosRog, Zymut, Kimoaen, Bwolfington and Anonymous: 75
• Memento pattern Source: https://en.wikipedia.org/wiki/Memento_pattern?oldid=733654845 Contributors: Ray Van De Walker, Heron,
Zeno Gantner, TakuyaMurata, Pcb21, Kingturtle, Hao2lian, RedWolf, BenFrantzDale, Zigmar, Abdull, Spoon!, Qwertyus, Stuart Yeates,
FlaBot, Alvin-cs, Zozakral~enwiki, JLaTondre, SmackBot, Royalguard11, Rajah9, DHN-bot~enwiki, Sardak, Chlewbot, JorisvS, Hu12,
Lathspell, Odie5533, Thijs!bot, VladM, Sushi Tax, Rich257, Abednigo, Aaron Rotenberg, Andy Dingley, Mormat, AlleborgoBot,
RobinHood70, Mild Bill Hiccup, Vghuston, Seethefellow, DumZiBoT, Addbot, LaaknorBot, Rubinbot, Klickverbot, Xqbot, MaheshZ,
Alainr345, Shadowjams, FrescoBot, Æneas, Bsivanov, CountRazumovsky, Alph Bot, Galyathee, Zymut, Tiagopsousa and Anonymous: 51
• Null Object pattern Source: https://en.wikipedia.org/wiki/Null_Object_pattern?oldid=771787386 Contributors: Timwi, Ferdinand Pien-
aar, Jpp, Abdull, Ice Keese~enwiki, Mahanga, Rjwilmsi, Hairy Dude, Zozakral~enwiki, Dirk Riehle, Cedar101, Snaxe920, Tom Morris,
SmackBot, Autarch, Frap, Cybercobra, Spiritia, 16@r, Neelix, Carlosayam, Paulecoyote, Ruijoel, Annrules, Andy Dingley, Ctxppc, Svick,
C xong, Nnemo, Mild Bill Hiccup, Addbot, Alexander Gorbylev, Teles, Jarble, Yobot, Bunnyhop11, Yossi Gil, AnomieBOT, Eofster,
Teukros, Citation bot 1, RandomDSdevel, EmausBot, Demonkoryu, Vaclav.Makes, MCSDWVL, Yegor256, Johndkane, ChrisGualtieri,
Codename Lisa, Michael Anon, Kwikkode, Me, Myself, and I are Here, Unclegene, Mmaaco, FGRibreau, Quitsspray, FinalCodeDrop,
ChuckTerry, Nklv, Rlss and Anonymous: 52
132 CHAPTER 6. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

• Observer pattern Source: https://en.wikipedia.org/wiki/Observer_pattern?oldid=772017008 Contributors: AxelBoldt, Ed Poor, Mrwojo,

Frecklefoot, Edward, Chris-martin, Kku, Komap, TakuyaMurata, Pcb21, Ronz, Jay, Nickg, Quux, Hao2lian, Furrykef, SD6-Agent, Rick-
Beton, RedWolf, Pingveno, KellyCoinGuy, Diderot, BenFrantzDale, Arturus~enwiki, Pashute, Bovlb, Khalid hassani, Uzume, Beland,
Kate, Leibniz, Mecanismo, Jarsyl, RoyBoy, Porton, RussBlau, Hooperbloob, TheParanoidOne, Philipp Weis, Stephan Leeds, Ceyockey,
Mahanga, Ariadie, Dionyziz, Prashanthns, David Levy, OMouse, Hyuga, Fred Bradstadt, FlaBot, Michaelschmatz, Alvin-cs, Lpsiphi,
Chobot, Peterl, YurikBot, Zozakral~enwiki, Retired username, Bkil, MatthieuWiki, Katieh5584, SmackBot, InverseHypercube, Eskim-
bot, Alexvaughan, Sam Pointon, Gilliam, Ohnoitsjamie, Autarch, SynergyBlades, OrangeDog, Nbarth, Darth Panda, Emurphy42, Can't
sleep, clown will eat me, Frap, OrphanBot, Radagast83, Shdwfeather, Robert Paveza, Albert cheng, Gang65, Wikidrone, Hu12, Sky-
Walker, Lnatan25, Gustavo.mori, CmdrObot, Pmussler, Eric Le Bigot, Karuppiah, Countchoc, Torc2, TheMuuj, Mattjball, Ebrahim,
Merutak, Thijs!bot, Hervegirod, Tmkeesey, VvV, Bdanee, Mzyxptlk, LazyEditor, Alphachimpbot, Xynopsis, MirkMeister, Abednigo,
Emw, Gwern, Kgeis, STBot, Willpwillp, Kelumnpk, BBilge, VolkovBot, Vipinhari, Anonymous Dissident, Anna Lincoln, Gregsinclair,
Aaron Rotenberg, Amazedsaint, Arnon Mathias, Jamelan, Mratzloff, Andy Dingley, Topdeck, YordanGeorgiev, Kstevenham, SieBot, To-
biasHerp, Sunnychow, ClueBot, Robbiemuffin, Emergeo, Niceguyedc, UKoch, Vghuston, Excirial, Sjmsteffann, Evertw, Lartoven, Oc666,
Diaa abdelmoneim, EcthelionGenesis, Bravegag, DumZiBoT, XLinkBot, C. lorenz, C3foncea, SlubGlub, Deineka, Addbot, SpellingBot,
Shirtwaist, Wbstory, Karl gregory jones, Ginosbot, OlEnglish, Razafy, Jarble, Jems420, OmveerChaudhary, Nallimbot, KamikazeBot,
SamuelHuckins, Vahrokh, AnomieBOT, CBMalloch, Götz, Decatur-en, Ipatrol, Xqbot, Redroof, Jebdm, Capricorn42, M.amjad.saeed,
Smk65536, Martnym, Kaquito, Rotaercz, Pmercier, Cosmin varlan, Vanished user giiw8u4ikmfw823foinc2, Terry.kfwong, Labviewpor-
tal, WikiSolved, Voyvf, Eknv, JnRouvignac, Marie Poise, DdEe4Aai, EmausBot, Nickolas.pohilets, Antonschastny, HurryPeter, Alejan-
dro.isaza, Petrb, ClueBot NG, Briefstyle, Cosmicnet, Reaper555, Bmusician, Yuqingalex, Alexlur, Sdesalas, Jphollanti, BattyBot, Per-
sonWhoLivesInHollyhurst, Devshop.me, Dexbot, Senthilblogs, Dough34, Arvindraivns, Zymut, Ch!p, JohnPython, Avijeetsahoo, Leem02
and Anonymous: 270
• Publish/subscribe Source: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern?oldid=755661806 Contributors: Ray
Van De Walker, Tedernst, Pnm, Kku, Mxn, Nickg, Aliekens, Altenmann, Enochlau, Beland, Abdull, Reflex Reaction, Dpm64, Melt-
Banana, Bender235, CanisRufus, Michael.jaeger, Carbon Caryatid, Harburg, Stephan Leeds, Suruena, Jacobolus, Peter Hitchmough, Ruud
Koot, Mandarax, Vegaswikian, Kmorozov, Chobot, YurikBot, Wavelength, Gaius Cornelius, FuzzyBSc, Spike Wilbury, DuncanCragg,
Bob Wyman, SmackBot, Stewartm82, Bostwickenator, JHunterJ, Edward Vielmetti, Pmerson, SymlynX, Neustradamus, Dougher, Robina
Fox, KagamiNoMiko, Fordsfords, Willpwillp, Group29, Marc Esnouf, S.borchers, Jamelan, Kstevenham, Kgardner2007, Tzoght, Jer-
ryobject, Ken Birman, Mild Bill Hiccup, Anaholic, Juergen.Boehm, Secretkeeper81, John at Lancelotlinc, XLinkBot, Cmcqueen1975,
WikHead, Subversive.sound, Addbot, Damiens.rf, LaaknorBot, , Yobot, Themfromspace, Bunnyhop11, Malin Tokyo, 4th-otaku, Ter-
vela, Mfrisch, L200817s, Kernel.package, Kyle Hardgrave, Berndfo, FrescoBot, Josemariasaldana, Hobsonlane, Francesco-lelli, Skyerise,
Bjfletcher, Obcg, ✓, Schollii, Clarevoyent, Supriyadevidutta, T.J.A. Uhm, ZéroBot, RichardBanks, Hidbaty223, ImaginationDave, Rich-
litt, Nanodance, Puffin, Lwihwr, ClueBot NG, KartikSinghal, BG19bot, Psy0rz, Jolest, BattyBot, Nick Stavros, B2u9vm1ea8g, Bagnolm,
Zhangsongyang, Venkykadali and Anonymous: 94
• Design pattern Servant Source: https://en.wikipedia.org/wiki/Servant_(design_pattern)?oldid=747842165 Contributors: Rudyment, Aza-
Toth, RHaworth, Qwertyus, Mathwiz777, Image of me, Ibic, Combovercool, Stfg, Aerovistae, Dthomsen8, Addbot, Twhitmore.nz, Ryoga
Godai, Yobot, Crionell, Invitrovanitas, Dexp, Beoros, VeselyBrumla, BG19bot, BattyBot, Happyser, Faisalbegins, Monkbot, Zorrinito and
Anonymous: 10
• Specification pattern Source: https://en.wikipedia.org/wiki/Specification_pattern?oldid=750388916 Contributors: B4hand, Kku, Rick-
Beton, Beland, CanisRufus, Zozakral~enwiki, Mirko Raner, SmackBot, MovGP0, Ivant, Torc2, Esowteric, Wavell2003, Andy Dingley,
Maralia, Addbot, Merarischroeder, Squishymaker, ‫רנדום‬, Svallory, AnomieBOT, FrescoBot, Juancadavid, Dewritech, Demonkoryu, Hap-
pyser, Cyberbot II, Sotonika, Ts.skowronski, Gilbertxenodike, Alexei.surovi, Narky Blert, Ofungus, Neoneye, WobblyWibbly, GreenC bot,
Code.Combustion, Agerace and Anonymous: 33
• State pattern Source: https://en.wikipedia.org/wiki/State_pattern?oldid=772241863 Contributors: TakuyaMurata, Julesd, Hao2lian, Red-
Wolf, Tea2min, BenFrantzDale, FunnyMan3595, Luigi30, LuckyStarr, Mecanismo, CanisRufus, Babomb, TheParanoidOne, Ruud Koot,
MithrandirMage, Subtractive, Roboto de Ajvol, YurikBot, Naasking, Cedar101, Frigoris, SmackBot, IanVaughan, Deltaflux, Allan
McInnes, Pilotguy, M4bwav, Joshua Scott, Edenphd, Hu12, Rory O'Kane, BennyD, Pmussler, Thijs!bot, ThomasO1989, Magioladitis,
Abednigo, JoaoTrindade, Jlechem, Jeepday, Pdhooper, Jamesontai, Suniltg, Mormat, Estevoaei, Garyczek, Vghuston, MystBot, Addbot,
MrOllie, Tassedethe, Matěj Grabovský, Xqbot, Sae1962, MastiBot, Userask, Eknv, Dinamik-bot, Hariharank12, Alph Bot, Laughmetal,
John of Reading, Ertwroc, Anonymous2420, Terheyden, Nitin.nizhawan, Helpful Pixie Bot, BG19bot, Cth027, Goddardpk, Nivedita-
Sancheti, Zymut and Anonymous: 57
• Strategy pattern Source: https://en.wikipedia.org/wiki/Strategy_pattern?oldid=764167838 Contributors: Hephaestos, Kku, TakuyaMu-
rata, Pcb21, Todd, Ronz, Marco Krohn, Jogloran, Hao2lian, Fredrik, RedWolf, Forseti, BenFrantzDale, Zhen Lin, Pgan002, Lst27,
Supadawg, Abdull, Flex, Rikesh kisnah, Southen, Remuel, TheParanoidOne, Ptyxs, Mahanga, Woohookitty, Ruud Koot, Qwertyus,
Dybowskijr, Platypus222, FlaBot, Quuxplusone, Riki, Roboto de Ajvol, Zozakral~enwiki, SpuriousQ, Mjchonoles, Ospalh, Cconnett,
Snaxe920, Mlibby, SmackBot, InverseHypercube, Bluebot, DHN-bot~enwiki, Spookylukey, Chlewbot, OrphanBot, Cybercobra, De-
cltype, Anupk7, Luís Felipe Braga, Edenphd, Loadmaster, Wikidrone, PeterRitchie, Hu12, Md2perpe, Pmussler, Equendil, XcepticZP,
Torc2, Thijs!bot, Jianwu, Hosamaly, Dougher, ThomasO1989, MER-C, Vladimir Bosnjak, Abednigo, Helmerh, Atree, Jpablo.romero,
The Wild Falcon, Landisdesign, TXiKiBoT, Dcadenas, JustinKoser, Liko81, Anirudhvyas010, TjerkWol~enwiki, Andy Dingley, Allebor-
goBot, EwgB, Sungur, Jerryobject, Radon210, Sumanthtamma, Tombomp, Denisarona, RobinHood70, Nnemo, Gluegadget, Vghuston,
M4gnum0n, MichalKwiatkowski, BOTarate, Wmwallace, Joswig, GeoffMacartney, SlubGlub, Addbot, PJonDevelopment, Jncraton, Cst17,
MrOllie, Jems420, Mik01aj, Yobot, AnomieBOT, Gradbot, Rubinbot, Obersachsebot, Redroof, Kingfishr, Thehelpfulbot, FrescoBot,
Sae1962, Pinethicket, DAVilla, Lotje, Ddonnell, Bocsika, Jonasschneider, EmausBot, Minddog, Richard.a.paul, AR15DUDE, Finked,
ClueBot NG, AustinBlues, BlueTaRaKa, MaxS 33, Pzrq, Ghazi20734, Vagobot, Daemonicky, Danny childs19, Ptoonen, Auraxangelic,
Omer Hassan, Aingeruzuria, Tafadzwakombe, Kameshwarg, DavidLeighEllis, Integralsun, Ap0st8c, Wenerme, Gf1809, Tim-bezhashvyly,
Kensenjohn, Dngache, SnowCambodia, Vgrund and Anonymous: 171
• Template method pattern Source: https://en.wikipedia.org/wiki/Template_method_pattern?oldid=768886472 Contributors: Roadrunner,
Mrwojo, Michael Hardy, TakuyaMurata, Ronz, Dysprosia, Hao2lian, Fredrik, RedWolf, BenFrantzDale, Chriki, Zhen Lin, Pne, T1mmyb,
Zarkonnen, Supadawg, Andreas Kaufmann, Remuel, TheParanoidOne, Oleg Alexandrov, Mahanga, Ruud Koot, Rjwilmsi, Vegaswikian,
Reinis, FlaBot, Quuxplusone, Rob*, Exe, YurikBot, Wavelength, Zozakral~enwiki, FF2010, LordTorgamus, Eskimbot, Frap, GiedrBac,
Antonielly, Edenphd, KJS77, Hu12, Iridescent, Pmussler, Cydebot, TJ09, Coconut99 99, Merutak, Dougher, MER-C, Vladimir Bosnjak,
Magioladitis, MiguelMunoz, Nyq, Jsmith030416, AleaB, Abednigo, Allstarecho, AllenDowney, Kgeis, Richard Katz, Mange01, LordAnu-
bisBOT, Dorftrottel, VolkovBot, TXiKiBoT, Liko81, Russell Triplehorn, Andy Dingley, LanceBarber, Mormat, AlleborgoBot, AHMartin,
6.1. TEXT 133

JonatanAndersson, Cp111, Vghuston, XLinkBot, Addbot, Normandomac, Pbyhistorian, Teles, Yobot, Ptbotgourou, AnomieBOT, Rubin-
bot, Anjsimmo, KJedi, Sae1962, Jonesey95, NuclearDuckie, Anonymous2420, Ontist, DaveLiu, David.moreno72, Klodr, Rafsan 033,
Jcodetips, Unnikked, Asorgiu, Remcelfr and Anonymous: 88
• Visitor pattern Source: https://en.wikipedia.org/wiki/Visitor_pattern?oldid=771572502 Contributors: Eob, TakuyaMurata, Karada,
Pcb21, Ronz, Gamma~enwiki, Andrewman327, Hao2lian, Phil Boswell, Fredrik, Mountain, RedWolf, Wlievens, Hadal, Lumingz,
Tea2min, Vir4030, BenFrantzDale, Beland, Int19h, Kate, Leibniz, Nchaimov, Sleske, VoluntarySlave, Forderud, Mcsee, Woohookitty,
MattGiuca, GregorB, Salix alba, FlaBot, Riki, YurikBot, Hairy Dude, Zozakral~enwiki, Gaius Cornelius, Wiki alf, Brandon, Nander-
man, Dethomas, Matthew0028, Pelister, Reyk, Luiscolorado, Alfredo.correa, SmackBot, Mitchan, Pkirlin, Eskimbot, Ohnoitsjamie, Jcar-
roll, Akanksh, Bluebot, Autarch, Theone256, DHN-bot~enwiki, Gyrobo, Gandalfgeek, Decltype, Kuru, Albert cheng, Edenphd, Poly-
Glot, Kvng, Hu12, Jokes Free4Me, Vinz83, Gnewf, Oerjan, Skarkkai, Fbahr, MER-C, Jrduncans, Magioladitis, Afsinbey, VoABot II,
Wikipodium, Cic, Ibic, Abednigo, Ftiercel, HGoat, Gwern, Hedwig in Washington, Ntalamai, Szeder, Alfatrion~enwiki, Kraftlos, Fyl-
wind, CardinalDan, Maghnus, Bennor, Anirudhvyas010, Andy Dingley, Fuhrmanator, Joel falcou~enwiki, Computerwguy, Jerryobject,
Pweifan, Svick, AlanUS, Iffypop, Devjava, Chris G Bot, PuercoPop, Bricegeumez, PipepBot, Alksentrs, Friskpeppermint, Vghuston,
M4gnum0n, Aeolian145, Bravegag, Versus22, Joswig, Thinking Stone, XLinkBot, C3foncea, MystBot, Addbot, Jjdawson7, Luckas-bot,
Yobot, AnomieBOT, Fizzbann1234, Billegge, Marau~enwiki, Materialscientist, Xqbot, Martnym, Sae1962, Mfwitten, B3t, Andy.m.jost,
Timenkov Fedor, Ржавый Хомяк, D chivaluri, Hajatvrc, EmausBot, JamesPoulson, Pewchies, Eight40, Sergei49, Hazard-SJ, Demonko-
ryu, ChuispastonBot, Prodigel, Anonymous2420, Objarni, My Name is Christopher, Rahab rx, Justincheng12345-bot, FoCuSandLeArN,
Goyalsachin22, Zymut, WansWeter, H662, Stokkie64, --, Dnesteruk, Kee.nam and Anonymous: 222
• Concurrency pattern Source: https://en.wikipedia.org/wiki/Concurrency_pattern?oldid=747226059 Contributors: Kku, Fredrik, Red-
Wolf, Khalid, TheParanoidOne, RJFJR, GregorB, Jopincar, Frap, Pcgomes, SashatoBot, Atreys, Casbah~enwiki, Torinthiel~enwiki, Magi-
oladitis, Mati22081979, Vinod.pahuja, Jogerh, Addbot, Luckas-bot, AshleySt, Sae1962, EmausBot, Ipsign, Enlilos, Sherbinko and Anony-
mous: 9
• Active object Source: https://en.wikipedia.org/wiki/Active_object?oldid=759572504 Contributors: Kku, Weeble, Beland, RHaworth,
Wigy, SmackBot, Stimpy, Tim@, JennyRad, Nbarth, Nixeagle, Tarcieri, Gingerjoos, ShakespeareFan00, Vegarwe, Keith D, Hans Adler,
Mitch Ames, Addbot, Zyx, Citation bot, Silesianus, Kobrabones, Trappist the monk, ZéroBot, Ipsign, BattyBot, Dexbot, 069952497a,
Wenerme, Zymut and Anonymous: 15
• Balking pattern Source: https://en.wikipedia.org/wiki/Balking_pattern?oldid=746485234 Contributors: Kku, TakuyaMurata, RedWolf,
DavidBrooks, Beland, Abdull, GregorB, Spliffy, Crystallina, SmackBot, Gwern, Jarble, Amiceli, Demonkoryu, Loopy48, Reify-tech,
Viperidaenz, Maiden taiwan and Anonymous: 12
• Messaging pattern Source: https://en.wikipedia.org/wiki/Messaging_pattern?oldid=764521786 Contributors: Beland, Abdull, Munahaf,
Anrie Nord, Prickus, Rwwww, SmackBot, Tinucherian, NunoAgostinho, 1000Faces, Djmackenzie, DumZiBoT, XLinkBot, Addbot, 4th-
otaku, JerryLerman, Lambda Magician, ChrisGualtieri, Dough34 and Anonymous: 19
• Double-checked locking Source: https://en.wikipedia.org/wiki/Double-checked_locking?oldid=764325639 Contributors: Taw, Freckle-
foot, TakuyaMurata, (, Haakon, ToastyKen, Julesd, RedWolf, Gracefool, Neilc, Beland, Andreas Kaufmann, RossPatterson, Rich Farm-
brough, Marudubshinki, E090, Ysangkok, YurikBot, Hairy Dude, Cryptic, Jyke, Jwir3, Nlu, Cedar101, SmackBot, Chronodm, PJTraill,
Jm307, Dripp, Dubwai, Doug Bell, Msundman, Jczeus, Bdawson, ShelfSkewed, AndrewHaley, Billyoneal, Wootery, Forbidder, Avisnacks,
Gwern, Javawizard, Billinghurst, Andy Dingley, Michaeldsuarez, Triesault, Initworks, SimonTrew, Quercus basaseachicensis, Alexbot,
XLinkBot, Addbot, Ghettoblaster, Atlaste, Bultro, Jarble, Yobot, AnomieBOT, Rubinbot, Digulla, Bbbush, Karl80, Dhvik, Mìthrandir,
Maggyero, I dream of horses, HRoestBot, Flyingped, BeeOnRope, Demonkoryu, AManWithNoPlan, ClueBot NG, MikeZar, Starry-
Grandma, Nikpantera, EdwardJKerley, Nurieta, Monkbot, Wenerme, Vikas.vksingh, InternetArchiveBot and Anonymous: 93
• Asynchronous method invocation Source: https://en.wikipedia.org/wiki/Asynchronous_method_invocation?oldid=764667365 Contrib-
utors: Pnm, Andreas Kaufmann, Abdull, Smalljim, Ron Ritzman, RHaworth, Uncle G, Qwertyus, Hairy Dude, JulesH, Cedar101, Smack-
Bot, JzG, Cydebot, Christian75, Cander0000, Aervanath, JL-Bot, Drmies, Hans Adler, Addbot, Freikorp, Davhdavh, HRoestBot, Trappist
the monk, DASHBot, Dcirovic, Ipsign, Sumeet.chhetri, Helpful Pixie Bot, BG19bot, Killjay89, Monkbot, Gpeja, WhyDoesSheRefuseTo-
HaveIntercourseWithMe, InternetArchiveBot, GreenC bot and Anonymous: 4
• Guarded suspension Source: https://en.wikipedia.org/wiki/Guarded_suspension?oldid=722162925 Contributors: TakuyaMurata, Pcb21,
HappyDog, Fredrik, CryptoDerk, Beland, Remuel, TheParanoidOne, MithrandirMage, TuukkaH, SmackBot, Reedy, Frap, Allan McInnes,
Citation bot, Amiceli, Citation bot 1, DrilBot, Loopy48 and Anonymous: 3
• Lock (computer science) Source: https://en.wikipedia.org/wiki/Lock_(computer_science)?oldid=767850805 Contributors: Zundark,
Taw, Edward, Nealmcb, TakuyaMurata, Dori, (, ²¹², Clausen, Jay, Zoicon5, Furrykef, Craig Stuntz, Altenmann, Tea2min, DavidCary,
Zigger, CyborgTosser, JimD, Jason Quinn, Neilc, Pgan002, Beland, Gazpacho, Ross bencina, KeyStroke, FT2, Wrp103, CanisRufus,
PaulMcKenney, Liao, Suruena, Jacobolus, Qwertyus, Rjwilmsi, Hathawayc, FlaBot, Maxal, Shivamohan, Quuxplusone, Chozan, Michael
Suess, YurikBot, RussBot, Michael Slone, Robert Will, Długosz, AnObfuscator, Gslin, SmackBot, Vald, OrangeDog, Allan McInnes,
Fuhghettaboutit, General Ization, Dicklyon, Torc2, Thijs!bot, McJaje, Hervegirod, Rsocol, Wmbolle, Magioladitis, SBunce, Gwern,
SJP, YB3, Zeroflag, Amorken, Wykypydya, Togamaru, Jerryobject, JCLately, Svick, Andahazy, Sun Creator, StanContributor, Erkin-
Batu, Addbot, Tothwolf, Lightbot, Omikronuk, Luckas-bot, Yobot, Amirobot, AnomieBOT, Kaycee srk, Mark Renier, Javier.eguiluz,
Sae1962, Roman12345, Maggyero, I dream of horses, Moonwolf14, Olawlor, Jfmantis, EmausBot, WikitanvirBot, GoingBatty, De-
monkoryu, Radik.khisamov, VictorianMutant, Danim, Helpful Pixie Bot, Saikrishna Chunchu, Dexbot, Softzen, Joshua.j.grossman,
SfEOaBx36VBaQKEL, B2u9vm1ea8g, Fmadd and Anonymous: 84
• Monitor (synchronization) Source: https://en.wikipedia.org/wiki/Monitor_(synchronization)?oldid=769326155 Contributors: Axel-
Boldt, Dcoetzee, Joy, Raul654, RickBeton, Jason Quinn, Abdull, Flex, Gazpacho, Mormegil, Rich Farmbrough, Bender235, Park-
landspanaway, John Vandenberg, Franl, Musiphil, Marudubshinki, Assimil8or~enwiki, Thomas Linder Puls, Intgr, Chobot, YurikBot,
Pburka, Cleared as filed, Waqas1987, Cedar101, JLaTondre, SmackBot, InverseHypercube, Ianb1469, Delldot, Charlesb, MalafayaBot,
Thiagomacieira, Chruck, Gennaro Prota, Yukoba~enwiki, Torc2, Dinnerbone, Thijs!bot, AntiVandalBot, Theodore.norvell, Gwern,
MartinBot, Niyue~enwiki, Fylwind, Rv74, Pdcook, Anna Lincoln, Wykypydya, Jerryobject, ClueBot, Gonnet, Moshewe, Niceguyedc,
Jeroen74~enwiki, Pacman128, Elizium23, Carriearchdale, DumZiBoT, Asafshelly, WikHead, Addbot, Tcncv, Leszek Jańczuk, Luckas-
bot, Yobot, GevorgVoskanyan1, Ipatrol, Xqbot, Miym, RibotBOT, Jacosi, FrescoBot, Moulaali, Craig Pemberton, I dream of horses,
TPReal, Surement, Ivanvector, DARTH SIDIOUS 2, Jfmantis, Herrturtur, John of Reading, AKEB~enwiki, Dewritech, GoingBatty,
Kislay kishore2003, ClueBot NG, Rinaku, Maarten Baert, Trevayne08, Chmarkine, Khazar2, Mtzguido, Quenhitran, Mohanagrawal13,
Arvindraivns, Monkbot, Nullptr, Jsg68x and Anonymous: 106
134 CHAPTER 6. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

• Reactor pattern Source: https://en.wikipedia.org/wiki/Reactor_pattern?oldid=693443491 Contributors: Chocolateboy, Danio, Vadmium,

Praxis, Hinrik, Apoc2400, Distalzou, Ehames, Mikeblas, Benjamin.booth, JLaTondre, Bigcheesegs, SmackBot, Jzawodn, Deli nk, Pkier-
ski, Krauss, Alaibot, Jaxelrod, Stevemurphy, Tedickey, JCarlos, Tomerfiliba, Gvanrossum, Slowpoison, Eugenejen, Fuhrmanator, David-
Bourguignon, Alejolp, M4gnum0n, PixelBot, UlrichAAB, XLinkBot, Modsaid, Addbot, Sfandino, Luckas-bot, AnomieBOT, Athaba,
Obankston, Iulian.serbanoiu, EmausBot, Ipsign, ClueBot NG, AmrinderAroraSW, Michael.john.kirk, Chmarkine, Jmg.utn, Pronskiy, Yb-
grey, Smoreno.uy, Fabiangergely, Apriendeau, Xpenxpen, Coralblocks and Anonymous: 52
• Readers-writer lock Source: https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock?oldid=763934862 Contributors: Pnm, Be-
land, Andreas Kaufmann, Spoonboy42, ZeroOne, Forderud, Qwertyus, Nihiltres, Quuxplusone, SmackBot, Vald, Thornrag, Ber, Darth
Panda, Malbrain, Ohconfucius, Dublet, Jeenuv, Fuzzbox, Msnicki, Furyhunter600, Greensburger, Peepeedia, Jakarr, Ronklein~enwiki,
KindDragon33, Pozdneev, Download, Yobot, Vanished user rt41as76lk, Miracleworker5263, FrescoBot, Maggyero, RandyFischer,
Loopy48, Floatjon, Dvyukov, Frietjes, Babobibo, Reify-tech, BG19bot, Monkbot and Anonymous: 19
• Scheduler pattern Source: https://en.wikipedia.org/wiki/Scheduling_(computing)?oldid=772079579 Contributors: Pit~enwiki, Nixdorf,
Kabads, Cyde, Karada, TomK32, Julesd, Andres, Charles Matthews, Jdstroy, Dcoetzee, Dysprosia, Espertus, Csurguine, Kristof vt, Mod-
ulatum, Ojigiri~enwiki, Tea2min, Kainaw, AlistairMcMillan, Jrdioko, Erd~enwiki, Beland, Rdsmith4, Huwr, Eric B. and Rakim, Abdull,
Mike Rosoft, Rich Farmbrough, Unixplumber, Bender235, ESkog, Ire and curses, Sleske, Nsaa, Guy Harris, Arthena, Diego Moya, Wen-
song~enwiki, Fasten, Suruena, Runtime, Amorymeltzer, Deathphoenix, Instantnood, Oleg Alexandrov, Woohookitty, Torqueing, GregorB,
Qwertyus, GeorgeBills, FlaBot, GünniX, BMF81, Bamnet, Wavelength, Nmondal, RussBot, Pi Delport, SteveLoughran, Bovineone, Rain-
drift, Moe Epsilon, Bkil, Pnorcks, Flooey, Banco~enwiki, Tribaal, K.Nevelsteen, ZabMilenko, Andyluciano~enwiki, JLaTondre, Simxp,
Thomas Blomberg, SmackBot, Moxon, Reedy, Robbie on rails, ToreN, KocjoBot~enwiki, Bluebot, TimBentley, Letdorf, Nbarth, Edge-
OfEpsilon, Rrelf, Zvar, Pax85, Raelus, Warren, Derek R Bullamore, Starlionblue, Soumyasch, Rythie, JHunterJ, Kvng, Hu12, Beno1000,
Markbassett, Le savoir et le savoir-faire, Kameraad Pjotr, Jesse Viviano, Tmn, ShelfSkewed, Alsu50, Penbat, Clappingsimon, Mblum-
ber, JPalonus, Thijs!bot, Saibo, Davidhorman, Tblackma222, Lyrric, Belzberg, Widefox, Dougher, NapoliRoma, BenjaminGittins, Jheiv,
Matt Kovacs, Bongwarrior, Dogface222, Dappawit, Nodekeeper, DGG, Mturilli, Church of emacs, Juggernaut the, Mange01, Okona,
Josh Tumath, Tewk, VolkovBot, Philip Trueman, Zidonuke, Dwhipps, The Wilschon, Sciencewatcher, Milan Keršláger, T.cucinotta, Big-
Dunc, Marrowmonkey, Pjoef, SieBot, Calliopejen1, Bitflow, Milan Kerslager, Love+-Zero, Jdaloner, StaticGull, ClueBot, Gigacephalus,
Niceguyedc, Excirial, M4gnum0n, Shaiguitar, Rhododendrites, Jshen6, Andy16666, Mjancuska, Ceriak, Roxy the dog, Dthomsen8, Mifter,
Dsimic, Deineka, Addbot, Ghettoblaster, Fluffernutter, Download, Tyw7, Tide rolls, Lightbot, ‫ماني‬, Bluebusy, Legobot, Yobot, Peter
Flass, AnomieBOT, Coolcoder, Erel Segal, Sz-iwbot, Materialscientist, Citation bot, TheAMmollusc, PabloCastellano, Capricorn42, Un-
ready, LAMurakami, Marckossa, Wnme, =Josh.Harris, FrescoBot, Cml5129, Astroman3D, Pinethicket, Reconsider the static, Vrena-
tor, Lysander89, Suffusion of Yellow, Voelp, Onel5969, JamieHanlon, John of Reading, Dewritech, Susfele, Anouarattn, IGeMiNix,
Carmichael, ClueBot NG, MelbourneStar, Widr, Heyandy889, Unixpickle, Bethuganesh32, BG19bot, Mazandar, BPositive, Kfcdesu-
land, BattyBot, Pratyya Ghosh, Cyberbot II, TwizteDope, Neils51, Doors5678, Dexbot, Ajinkyaj, Kushalbiswas777, Frantxesco, Michael
Anon, Lugia2453, Graphium, Jamesx12345, Mahbubur-r-aaman, Seanhalle, Echinacin35, MFuog, Comp.arch, Flankattack, Sushrut mi,
Apoorva181192, Vpnmthw812, ScotXW, Skr15081997, Philippe97, Sebwills, Ricketybridge, Kinetic37, MRD2014, KH-1, Avikalpgupta,
Infinite0694, JessicaGibbs, DatGuy, Sharradan, Ehenri90, GreenC bot, PRUPAREL and Anonymous: 348
• Thread pool pattern Source: https://en.wikipedia.org/wiki/Thread_pool?oldid=754748772 Contributors: Ewen, Julesd, Charles
Matthews, RickBeton, RedWolf, Check~enwiki, Andreas Kaufmann, Abdull, CanisRufus, Cburnett, Qwertyus, Psm, Ysangkok, Ph11,
Leuk he, Nbarth, JonHarder, Cybercobra, Doug Bell, Soumyasch, Bezenek, Cydebot, Iceman42, Swpb, Stokestack, Gwern, Red Thrush,
Kbrose, Jdavidw13, Arkanosis, Caitlinhalstead, MystBot, Addbot, Ghettoblaster, LarryJeff, AnomieBOT, Swguy3, VadimIppolitov, I
dream of horses, Denny-cn, Adrian hipgeek, Asimahme tx1, Brycehughes, Ptrb, ChrisGualtieri, Rarkenin, Enterprisey, Viam Ferream,
Foundationsend and Anonymous: 36
• Thread-local storage Source: https://en.wikipedia.org/wiki/Thread-local_storage?oldid=770553810 Contributors: NathanBeach, William
Avery, Heron, B4hand, Rvalles, Raul654, Tea2min, Jorend, Andreas Kaufmann, Qutezuce, Pavel Vozenilek, Bender235, Park-
landspanaway, AKGhetto, Nealcardwell, Suruena, Forderud, Gerbrant, Marudubshinki, KamasamaK, RussBot, Jengelh, ENeville, LeoN-
erd, CyberShadow, Mais oui!, SmackBot, Brianski, Toddintr, Hmains, Bluebot, TimBentley, Thumperward, Nbarth, Tackline, Frap, Doug
Bell, JoeBot, KazKylheku, Raysonho, SJFriedl, AndrewHowse, Cydebot, Christian75, Pjvpjv, Adarnvoid, Martinkunev, Gwern, Anda-
reed, Mangotang, VolkovBot, Lanzkron, Philip Trueman, Hutteman, Jerryobject, Thomerow, SimonTrew, Ctxppc, BevinBrett, Svick,
D.scain.farenzena, CohesionBot, Alexbot, Scottielad, SteveMao, Asafshelly, Addbot, Scientus, Numbo3-bot, Luckas-bot, Yobot, Florian
Weber, Xqbot, F. Saerdna, FrescoBot, LucienBOT, Winterst, I dream of horses, Antithesisw, RjwilmsiBot, Demonkoryu, Richard1962,
Crististm, BG19bot, Cyberbot II, Rarkenin, Softzen, 4costlygrace and Anonymous: 75

6.2 Images
• File:Abstract_Factory_in_LePUS3_vector.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/54/Abstract_Factory_in_
LePUS3_vector.svg License: Public domain Contributors: File:Abstract Factory in LePUS3.png Original artist: Amnon Eden
• File:Abstract_factory.svg Source: https://upload.wikimedia.org/wikipedia/commons/a/a7/Abstract_factory.svg License: CC-BY-SA-
3.0 Contributors: Recreation of Abstract_factory.png by Bdean42 in SVG format. Original artist: <a href='//commons.wikimedia.
org/wiki/User:DoktorMandrake' class='mw-redirect' title='User:DoktorMandrake'>Doktor</a><a href='//commons.wikimedia.org/wiki/
User_talk:DoktorMandrake' class='mw-redirect' title='User talk:DoktorMandrake'>Mandrake</a>
• File:Abstract_factory_UML.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/9d/Abstract_factory_UML.svg License:
CC-BY-SA-3.0 Contributors: My own work, generated with omondo for eclipse 3.1.2, modified with inkscape. Original artist: Giacomo
Ritucci
• File:Adapter(Class)_pattern_in_LePUS3.png Source: https://upload.wikimedia.org/wikipedia/en/b/b3/Adapter%28Class%29_
pattern_in_LePUS3.png License: CC-BY-SA-3.0 Contributors:
self-made
Original artist:
Edenphd
• File:Adapter(Object)_pattern_in_LePUS3.png Source: https://upload.wikimedia.org/wikipedia/commons/1/1a/Adapter%28Object%
29_pattern_in_LePUS3.png License: Public domain Contributors: Own work Original artist: Amnon Eden (User:Edenphd)
6.2. IMAGES 135

• File:Ambox_important.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/b4/Ambox_important.svg License: Public do-

main Contributors: Own work, based off of Image:Ambox scales.svg Original artist: Dsmurat (talk · contribs)
• File:Bridge_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/c/cf/Bridge_UML_class_diagram.
svg License: Public domain Contributors: My own work, written with text editor. Original artist: Trashtoy
• File:Bridge_pattern_in_LePUS3.1.gif Source: https://upload.wikimedia.org/wikipedia/commons/a/a8/Bridge_pattern_in_LePUS3.1.
gif License: Public domain Contributors: Amnon Eden (User:Edenphd) Original artist: Ian Atkin (User:Sugarfish) [correction of image
originally created by Amnon Eden (User:Edenphd)]
• File:Builder_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/f/f3/Builder_UML_class_diagram.
svg License: Public domain Contributors: My own work, written with text editor. Original artist: Trashtoy
• File:ClassAdapter.png Source: https://upload.wikimedia.org/wikipedia/commons/3/35/ClassAdapter.png License: Public domain Con-
tributors: Transferred from en.wikipedia to Commons by Vinhtantran. Original artist: GilHamilton at English Wikipedia
• File:Command_pattern.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/bf/Command_pattern.svg License: CC BY-SA
4.0 Contributors: Own work Original artist: Sae1962
• File:Commons-logo.svg Source: https://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: PD Contributors: ? Origi-
nal artist: ?
• File:Composite_UML_class_diagram_(fixed).svg Source: https://upload.wikimedia.org/wikipedia/commons/5/5a/Composite_UML_
class_diagram_%28fixed%29.svg License: Public domain Contributors:
• Composite_UML_class_diagram.svg Original artist: Composite_UML_class_diagram.svg: Trashtoy
• File:Composite_pattern_in_LePUS3.png Source: https://upload.wikimedia.org/wikipedia/commons/a/a9/Composite_pattern_in_
LePUS3.png License: Public domain Contributors: Own work Original artist: Amnon Eden (User:Edenphd)
• File:Creational_Pattern_Simple_Structure.png Source: https://upload.wikimedia.org/wikipedia/en/f/f6/Creational_Pattern_Simple_
Structure.png License: CC-BY-3.0 Contributors: ? Original artist: ?
• File:Decorator_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/e/e9/Decorator_UML_class_
diagram.svg License: Public domain Contributors: My own work, written with text editor. Original artist: Trashtoy
• File:DesignPatternServantFigure1.png Source: https://upload.wikimedia.org/wikipedia/commons/3/38/DesignPatternServantFigure1.
png License: CC BY-SA 3.0 Contributors: Own work Original artist: VeselyBrumla
• File:DesignPatternServantFigure2.png Source: https://upload.wikimedia.org/wikipedia/commons/4/41/DesignPatternServantFigure2.
png License: CC BY-SA 3.0 Contributors: Own work Original artist: VeselyBrumla
• File:Desktop_computer_clipart_-_Yellow_theme.svg Source: https://upload.wikimedia.org/wikipedia/commons/d/d7/Desktop_
computer_clipart_-_Yellow_theme.svg License: CC0 Contributors: https://openclipart.org/detail/17924/computer Original artist: AJ from
openclipart.org
• File:Edit-clear.svg Source: https://upload.wikimedia.org/wikipedia/en/f/f2/Edit-clear.svg License: Public domain Contributors: The
Tango! Desktop Project. Original artist:
The people from the Tango! project. And according to the meta-data in the file, specifically: “Andreas Nilsson, and Jakub Steiner (although
minimally).”
• File:Example_of_Facade_design_pattern_in_UML.png Source: https://upload.wikimedia.org/wikipedia/en/5/57/Example_of_
Facade_design_pattern_in_UML.png License: CC-BY-SA-3.0 Contributors:
I created this diagram using PlantUML.com
Original artist:
Fuhrmanator
• File:Front_Controller.svg Source: https://upload.wikimedia.org/wikipedia/commons/8/8e/Front_Controller.svg License: CC BY-SA 3.0
Contributors: Own work Original artist: MovGP0
• File:Interpreter_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/b/bc/Interpreter_UML_class_
diagram.svg License: CC BY-SA 4.0 Contributors: Own work Original artist: Sae1962
• File:Iterator_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/1/13/Iterator_UML_class_diagram.
svg License: Public domain Contributors: My own work written with text editor. Original artist: Trashtoy
• File:LampFlowchart.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/91/LampFlowchart.svg License: CC-BY-SA-3.0
Contributors: vector version of Image:LampFlowchart.png Original artist: svg by Booyabazooka

• File:Lock-green.svg Source: https://upload.wikimedia.org/wikipedia/commons/6/65/Lock-green.svg License: CC0 Contributors: en:File:

Free-to-read_lock_75.svg Original artist: User:Trappist the monk
• File:Mediator_design_pattern.png Source: https://upload.wikimedia.org/wikipedia/commons/e/e4/Mediator_design_pattern.png Li-
cense: Public domain Contributors: Own work Original artist: Kostyantyn Yuriyovich Kolesnichenko
• File:Monitor_(synchronization)-Java.png Source: https://upload.wikimedia.org/wikipedia/commons/f/f5/Monitor_
%28synchronization%29-Java.png License: CC BY 3.0 Contributors: Own work Original artist: Theodore.norvell (talk)
• File:Monitor_(synchronization)-Mesa.png Source: https://upload.wikimedia.org/wikipedia/commons/1/15/Monitor_
%28synchronization%29-Mesa.png License: CC BY 3.0 Contributors: Own work Original artist: Theodore.norvell (talk)
• File:Monitor_(synchronization)-SU.png Source: https://upload.wikimedia.org/wikipedia/commons/d/db/Monitor_
%28synchronization%29-SU.png License: CC BY 3.0 Contributors: Own work Original artist: User:Theodore.norvell
• File:Multiton.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/9f/Multiton.svg License: CC0 Contributors: Own work
Original artist: Sae1962
136 CHAPTER 6. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES

• File:New_WikiFactoryMethod.png Source: https://upload.wikimedia.org/wikipedia/commons/d/df/New_WikiFactoryMethod.png Li-

cense: CC BY-SA 4.0 Contributors: Own work Original artist: Rforuupt
• File:ObjectAdapter.png Source: https://upload.wikimedia.org/wikipedia/commons/d/d7/ObjectAdapter.png License: Public domain
Contributors: Transferred from en.wikipedia to Commons by Vinhtantran. Original artist: GilHamilton at English Wikipedia
• File:Observer.svg Source: https://upload.wikimedia.org/wikipedia/commons/8/8d/Observer.svg License: Public domain Contributors:
Own work Original artist: WikiSolved
• File:Prototype_UML.svg Source: https://upload.wikimedia.org/wikipedia/commons/1/14/Prototype_UML.svg License: CC-BY-SA-3.0
Contributors: my own work, generated with omondo (eclipse plugin) and edited with inkscape Original artist: User:Giacomo Ritucci
• File:Proxy_pattern_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/7/75/Proxy_pattern_diagram.svg License:
CC-BY-SA-3.0 Contributors: en:Image:Proxy pattern diagram.png Original artist: Traced by User:Stannered, created by en:User:
TravisHein
• File:Proxy_pattern_in_LePUS3.gif Source: https://upload.wikimedia.org/wikipedia/commons/7/79/Proxy_pattern_in_LePUS3.gif Li-
cense: CC BY-SA 3.0 Contributors: Own work Original artist: Amnon Eden (talk)
• File:Question_book-new.svg Source: https://upload.wikimedia.org/wikipedia/en/9/99/Question_book-new.svg License: Cc-by-sa-3.0
Contributors:
Created from scratch in Adobe Illustrator. Based on Image:Question book.png created by User:Equazcion Original artist:
Tkgd2007
• File:Simplified_Structure_of_the_Linux_Kernel.svg Source: https://upload.wikimedia.org/wikipedia/commons/6/65/Simplified_
Structure_of_the_Linux_Kernel.svg License: CC BY-SA 4.0 Contributors: Own work Original artist: ScotXW
• File:Singleton_UML_class_diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/f/fb/Singleton_UML_class_
diagram.svg License: Public domain Contributors: My own work, written with text editor. Original artist: Trashtoy
• File:Software_spanner.png Source: https://upload.wikimedia.org/wikipedia/commons/8/82/Software_spanner.png License: CC-BY-
SA-3.0 Contributors: Transferred from en.wikipedia to Commons by Rockfang. Original artist: CharlesC at English Wikipedia
• File:Specification_UML_v2.png Source: https://upload.wikimedia.org/wikipedia/commons/8/8b/Specification_UML_v2.png License:
GFDL Contributors: http://en.wikipedia.org/wiki/File:Specification_UML.png Original artist: IToshkov
• File:State_Design_Pattern_UML_Class_Diagram.svg Source: https://upload.wikimedia.org/wikipedia/commons/e/e8/State_Design_
Pattern_UML_Class_Diagram.svg License: CC BY-SA 3.0 Contributors:
• State_Design_Pattern_UML_Class_Diagram.png Original artist: State_Design_Pattern_UML_Class_Diagram.png: JoaoTrindade (talk)
• File:State_pattern_in_LePUS3.gif Source: https://upload.wikimedia.org/wikipedia/commons/9/9b/State_pattern_in_LePUS3.gif Li-
cense: Public domain Contributors: Own work Original artist: Amnon Eden (User:Edenphd)
• File:StrategyPattern_IBrakeBehavior.svg Source: https://upload.wikimedia.org/wikipedia/commons/4/4b/StrategyPattern_
IBrakeBehavior.svg License: CC0 Contributors: wikimedia Original artist: Bocsika
• File:Strategy_Pattern_in_UML.png Source: https://upload.wikimedia.org/wikipedia/commons/3/39/Strategy_Pattern_in_UML.png
License: Public domain Contributors: http://www.mcdonaldland.info/2007/11/28/40/ Original artist: Jason S. McDonald
• File:Strategy_pattern_in_LePUS3.gif Source: https://upload.wikimedia.org/wikipedia/commons/d/d9/Strategy_pattern_in_LePUS3.
gif License: Public domain Contributors: Own work Original artist: Amnon Eden (User:Edenphd)
• File:Template_Method_UML.svg Source: https://upload.wikimedia.org/wikipedia/commons/5/52/Template_Method_UML.svg Li-
cense: CC-BY-SA-3.0 Contributors: Own work Original artist: Giacomo Ritucci
• File:Template_Method_pattern_in_LePUS3.gif Source: https://upload.wikimedia.org/wikipedia/commons/2/2a/Template_Method_
pattern_in_LePUS3.gif License: Public domain Contributors: Own work Original artist: Amnon Eden (User:Edenphd)
• File:Text_document_with_red_question_mark.svg Source: https://upload.wikimedia.org/wikipedia/commons/a/a4/Text_document_
with_red_question_mark.svg License: Public domain Contributors: Created by bdesham with Inkscape; based upon Text-x-generic.svg
from the Tango project. Original artist: Benjamin D. Esham (bdesham)
• File:Thread_pool.svg Source: https://upload.wikimedia.org/wikipedia/commons/0/0c/Thread_pool.svg License: CC-BY-SA-3.0 Con-
tributors: Own work in Inkscape Original artist: en:User:Cburnett
• File:UML2_Decorator_Pattern.png Source: https://upload.wikimedia.org/wikipedia/commons/c/c6/UML2_Decorator_Pattern.png Li-
cense: CC BY-SA 3.0 Contributors: Own work (Original text: I (Nheirbaut (talk)) created this work entirely by myself.) Original artist:
Nheirbaut (talk)
• File:UML_diagram_of_an_example_of_the_Visitor_design_pattern.png Source: https://upload.wikimedia.org/wikipedia/en/d/d9/
UML_diagram_of_an_example_of_the_Visitor_design_pattern.png License: CC-BY-SA-3.0 Contributors:
Using the PlantUML software
Original artist:
Fuhrmanator
• File:Visitor_design_pattern.svg Source: https://upload.wikimedia.org/wikipedia/en/e/eb/Visitor_design_pattern.svg License: CC-BY-
3.0 Contributors: ? Original artist: ?
• File:Wikibooks-logo-en-noslogan.svg Source: https://upload.wikimedia.org/wikipedia/commons/d/df/Wikibooks-logo-en-noslogan.
svg License: CC BY-SA 3.0 Contributors: Own work Original artist: User:Bastique, User:Ramac et al.
• File:Wikiversity-logo.svg Source: https://upload.wikimedia.org/wikipedia/commons/9/91/Wikiversity-logo.svg License: CC BY-SA 3.0
Contributors: Snorky (optimized and cleaned up by verdy_p) Original artist: Snorky (optimized and cleaned up by verdy_p)
• File:Диаграма2.gif Source: https://upload.wikimedia.org/wikipedia/commons/e/eb/%D0%94%D0%B8%D0%B0%D0%B3%D1%
80%D0%B0%D0%BC%D0%B02.gif License: GFDL Contributors: Own work Original artist: Iliya.Velkov

6.3 Content license

• Creative Commons Attribution-Share Alike 3.0