Combining design patterns
(→Patterns Using Inheritance) |
|||
| Line 19: | Line 19: | ||
Note: the class vs object [[Encapsulation boundary]] becomes very important here. | Note: the class vs object [[Encapsulation boundary]] becomes very important here. | ||
| + | == Composite + X == | ||
| + | Thoughts? | ||
{{design patterns}} | {{design patterns}} | ||
Revision as of 01:10, 5 August 2009
Design patterns can be combined in numerous interesting ways to create super-patterns aka OO programs. A great example of this being done well is JUnit.
Contents |
Singleton + X
The singleton can be combined with a wide variety of patterns to create more specialised behaviour.
Proxy
By using a singleton on certain parts of a proxy a specific effect can be generated.
- Real Subject - Adding a singleton here means that any number of proxys can access this one class. This creates a specialised behaviour where different proxies can access a central object in different ways without being concerned that the right object is being called.
- Proxy - A singleton here makes sure that only a single proxy can be used to call any subject.
- Subject - A simple singleton here breaks the proxy pattern as no subclasses are allowed. A complex singleton, i.e. one that allows a controlled number of instances could be very powerful.
Facade
This is often a logical approach as it makes obtaining the correct object to access the complex system underneath straightforward.
Patterns Using Inheritance
- Superclass - Out of all of the subclasses there may only be one instance.
- Subclasses - Allows the inheritance hierarchy to have controlled constraints. See the attached image.
Note: the class vs object Encapsulation boundary becomes very important here.
Composite + X
Thoughts?
| Design patterns | |
|---|---|
|
Creational: Abstract Factory | Builder | Factory Method | Prototype | Singleton | |
