Combining design patterns
(→Facade) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by JaninaVoigt) |
||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | 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]]. | + | 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]]. The [[Gang of Four 1995]] text also mentions the combination of patterns, with each chapter having a small section on related patterns. |
== [[Singleton]] + X == | == [[Singleton]] + X == | ||
| Line 12: | Line 12: | ||
=== Patterns Using Inheritance === | === Patterns Using Inheritance === | ||
| + | [[Image:InheritanceSingleton.png|right|thumb|The power of using a singleton in the inheritance hierachy]] | ||
| + | * '''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. | |
| + | |||
| + | == [[Observer]] + X == | ||
| + | === [[Observer]] === | ||
| + | * While I suppose it would be technically possible for an object to observe itself, I can't think of a pratical purpose for this. | ||
| + | * However, chaining observers together to add new information/functionality at each step is a possible technique. | ||
| + | |||
| + | === [[Mediator]] === | ||
| + | |||
| + | The [[Observer]] pattern could be very useful when combined with [[Mediator]]. Mediators need to be informed by the colleagues when a change occurs so that they can inform other colleague objects. There is a two-way association here: mediators have to know about colleagues so they can update them when necessary and colleagues need to know about mediators so they can let them know of any changes that other colleagues may need to be informed of. | ||
| + | |||
| + | Observer can help to loosen this two-way association, thus reducing coupling between mediators and colleagues. The mediator could be the observer and the colleagues could be the subject, informing the observer whenever changes happen. | ||
| + | |||
| + | == [[Composite]] + X == | ||
| + | Thoughts? | ||
Latest revision as of 03:18, 25 November 2010
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. The Gang of Four 1995 text also mentions the combination of patterns, with each chapter having a small section on related patterns.
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.
Observer + X
Observer
- While I suppose it would be technically possible for an object to observe itself, I can't think of a pratical purpose for this.
- However, chaining observers together to add new information/functionality at each step is a possible technique.
Mediator
The Observer pattern could be very useful when combined with Mediator. Mediators need to be informed by the colleagues when a change occurs so that they can inform other colleague objects. There is a two-way association here: mediators have to know about colleagues so they can update them when necessary and colleagues need to know about mediators so they can let them know of any changes that other colleagues may need to be informed of.
Observer can help to loosen this two-way association, thus reducing coupling between mediators and colleagues. The mediator could be the observer and the colleagues could be the subject, informing the observer whenever changes happen.
Composite + X
Thoughts?
