|
9 | 9 | ##Abstract Factory |
10 | 10 | **Intent:** Provide an interface for creating families of related or dependent objects without specifying their concrete classes. |
11 | 11 |
|
12 | | - |
| 12 | + |
13 | 13 |
|
14 | 14 | **Applicability:** Use the Abstract Factory pattern when |
15 | 15 | * a system should be independent of how its products are created, composed and represented |
|
20 | 20 | ##Builder |
21 | 21 | **Intent:** Separate the construction of a complex object from its representation so that the same construction process can create different representations. |
22 | 22 |
|
23 | | - |
| 23 | + |
24 | 24 |
|
25 | 25 | **Applicability:** Use the Builder pattern when |
26 | 26 | * the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled |
|
29 | 29 | ##Factory Method |
30 | 30 | **Intent:** Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. |
31 | 31 |
|
32 | | - |
| 32 | + |
33 | 33 |
|
34 | 34 | **Applicability:** Use the Factory Method pattern when |
35 | 35 | * a class can't anticipate the class of objects it must create |
|
39 | 39 | ##Prototype |
40 | 40 | **Intent:** Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. |
41 | 41 |
|
42 | | - |
| 42 | + |
43 | 43 |
|
44 | 44 | **Applicability:** Use the Prototype pattern when a system should be independent of how its products are created, composed and represented; and |
45 | 45 | * when the classes to instantiate are specified at run-time, for example, by dynamic loading; or |
|
49 | 49 | ##Singleton |
50 | 50 | **Intent:** Ensure a class only has one instance, and provide a global point of access to it. |
51 | 51 |
|
52 | | - |
| 52 | + |
53 | 53 |
|
54 | 54 | **Applicability:** Use the Singleton pattern when |
55 | 55 | * the must be exactly one instance of a class, and it must be accessible to clients from a well-known access point |
|
58 | 58 | ##Adapter |
59 | 59 | **Intent:** Convert the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. |
60 | 60 |
|
61 | | - |
| 61 | + |
62 | 62 |
|
63 | 63 | **Applicability:** Use the Adapter pattern when |
64 | 64 | * you want to use an existing class, and its interface does not match the one you need |
|
69 | 69 | **Intent:** Decouple an abstraction from its implementation so that the two can vary independently. |
70 | 70 |
|
71 | 71 |
|
72 | | - |
| 72 | + |
73 | 73 |
|
74 | 74 | **Applicability:** Use the Bridge pattern when |
75 | 75 | * you want to avoid a permanent binding between an abstraction and its implementation. This might be the case, for example, when the implementation must be selected or switched at run-time. |
|
81 | 81 | ##Composite |
82 | 82 | **Intent:** Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. |
83 | 83 |
|
84 | | - |
| 84 | + |
85 | 85 |
|
86 | 86 | **Applicability:** Use the Composite pattern when |
87 | 87 | * you want to represent part-whole hierarchies of objects |
|
90 | 90 | ##Decorator |
91 | 91 | **Intent:** Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. |
92 | 92 |
|
93 | | - |
| 93 | + |
94 | 94 |
|
95 | 95 | **Applicability:** Use Decorator |
96 | 96 | * to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects |
|
100 | 100 | ##Facade |
101 | 101 | **Intent:** Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use. |
102 | 102 |
|
103 | | - |
| 103 | + |
104 | 104 |
|
105 | 105 | **Applicability:** Use the Facade pattern when |
106 | 106 | * you want to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but is also becomes harder to use for clients that don't need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade. |
|
110 | 110 | ##Flyweight |
111 | 111 | **Intent:** Use sharing to support large numbers of fine-grained objects efficiently. |
112 | 112 |
|
113 | | - |
| 113 | + |
114 | 114 |
|
115 | 115 | **Applicability:** The Flyweight pattern's effectiveness depends heavily on how and where it's used. Apply the Flyweight pattern when all of the following are true |
116 | 116 | * an application uses a large number of objects |
|
122 | 122 | ##Proxy |
123 | 123 | **Intent:** Provide a surrogate or placeholder for another object to control access to it. |
124 | 124 |
|
125 | | - |
| 125 | + |
126 | 126 |
|
127 | 127 | **Applicability:** Proxy is applicable whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer. here are several common situations in which the Proxy pattern is applicable |
128 | 128 | * a remote proxy provides a local representative for an object in a different address space. |
|
132 | 132 | ##Chain of responsibility |
133 | 133 | **Intent:** Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. |
134 | 134 |
|
135 | | - |
| 135 | + |
136 | 136 |
|
137 | 137 | **Applicability:** Use Chain of Responsibility when |
138 | 138 | * more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically |
|
142 | 142 | ##Command |
143 | 143 | **Intent:** Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. |
144 | 144 |
|
145 | | - |
| 145 | + |
146 | 146 |
|
147 | 147 | **Applicability:** Use the Command pattern when you want to |
148 | 148 | * parameterize objects by an action to perform. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks. |
|
154 | 154 | ##Interpreter |
155 | 155 | **Intent:** Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language. |
156 | 156 |
|
157 | | - |
| 157 | + |
158 | 158 |
|
159 | 159 | **Applicability:** Use the Interpreter pattern when there is a language to interpret, and you can represent statements in the language as abstract syntax trees. The Interpreter pattern works best when |
160 | 160 | * the grammar is simple. For complex grammars, the class hierarchy for the grammar becomes large and unmanageable. Tools such as parser generators are a better alternative in such cases. They can interpret expressions without building abstract syntax trees, which can save space and possibly time |
|
163 | 163 | ##Iterator |
164 | 164 | **Intent:** Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. |
165 | 165 |
|
166 | | - |
| 166 | + |
167 | 167 |
|
168 | 168 | **Applicability:** Use the Iterator pattern |
169 | 169 | * to access an aggregate object's contents without exposing its internal representation |
|
173 | 173 | ##Mediator |
174 | 174 | **Intent:** Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. |
175 | 175 |
|
176 | | - |
| 176 | + |
177 | 177 |
|
178 | 178 | **Applicability:** Use the Mediator pattern when |
179 | 179 | * a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand |
|
183 | 183 | ##Memento |
184 | 184 | **Intent:** Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. |
185 | 185 |
|
186 | | - |
| 186 | + |
187 | 187 |
|
188 | 188 | **Applicability:** Use the Memento pattern when |
189 | 189 | * a snapshot of an object's state must be saved so that it can be restored to that state later, and |
|
192 | 192 | ##Model-View-Presenter |
193 | 193 | **Intent:** Apply a "Separation of Concerns" principle in a way that allows developers to build and test user interfaces. |
194 | 194 |
|
195 | | - |
| 195 | + |
196 | 196 |
|
197 | 197 | **Applicability:** Use the Model-View-Presenter in any of the following situations |
198 | 198 | * when you want to improve the "Separation of Concerns" principle in presentation logic |
|
201 | 201 | ##Observer |
202 | 202 | **Intent:** Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. |
203 | 203 |
|
204 | | - |
| 204 | + |
205 | 205 |
|
206 | 206 | **Applicability:** Use the Observer pattern in any of the following situations |
207 | 207 | * when an abstraction has two aspects, one dependent on the other. Encapsulating these aspects in separate objects lets you vary and reuse them independently |
|
211 | 211 | ##State |
212 | 212 | **Intent:** Allow an object to alter its behavior when its internal state changes. The object will appear to change its class. |
213 | 213 |
|
214 | | - |
| 214 | + |
215 | 215 |
|
216 | 216 | **Applicability:** Use the State pattern in either of the following cases |
217 | 217 | * an object's behavior depends on its state, and it must change its behavior at run-time depending on that state |
|
220 | 220 | ##Strategy |
221 | 221 | **Intent:** Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. |
222 | 222 |
|
223 | | - |
| 223 | + |
224 | 224 |
|
225 | 225 | **Applicability:** Use the Strategy pattern when |
226 | 226 | * many related classes differ only in their behavior. Stratefies provide a way to configure a class eith one of many behaviors |
|
231 | 231 | ##Template method |
232 | 232 | **Intent:** Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. |
233 | 233 |
|
234 | | - |
| 234 | + |
235 | 235 |
|
236 | 236 | **Applicability:** The Template Method pattern should be used |
237 | 237 | * to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary |
|
241 | 241 | ##Visitor |
242 | 242 | **Intent:** Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates. |
243 | 243 |
|
244 | | - |
| 244 | + |
245 | 245 |
|
246 | 246 | **Applicability:** Use the Visitor pattern when |
247 | 247 | * an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes |
|
251 | 251 | ##Double Checked Locking |
252 | 252 | **Intent:** Reduce the overhead of acquiring a lock by first testing the locking criterion (the "lock hint") without actually acquiring the lock. Only if the locking criterion check indicates that locking is required does the actual locking logic proceed. |
253 | 253 |
|
254 | | - |
| 254 | + |
255 | 255 |
|
256 | 256 | **Applicability:** Use the Double Checked Locking pattern when |
257 | 257 | * there is a concurrent access in object creation, e.g. singleton, where you want to create single instance of the same class and checking if it's null or not maybe not be enough when there are two or more threads that checks if instance is null or not. |
|
0 commit comments