Similar patterns and how to tell them apart
This page is for gathering information about design patterns that are similar in some way with information on how to distinguish between them. In particular, some patterns look very similar but can be distinguished because their purposes are different, while other patterns have similar purposes but are different in terms of their structure. Hopefully, this will be helpful for our exam study.
Contents |
Facade and Mediator
These two patterns have very similar purposes in that they both attempt to abstract communications between objects. They are different because:
- For the Facade pattern, clients don't know that they are talking to a facade rather than the actual subsystem it abstracts. For Mediator the objects communicating through the mediator are aware that they are communicating with a mediator rather than with the other colleagues directly.
- In the Facade pattern, the facade communicates with the subsystem but the subsystem knows nothing about the facade so the communication / knowledge is one-way only. In the Mediator pattern, the mediator knows about and communicates with the colleagues and the colleagues know about and communicate with the mediator so communication / knowledge is two-way.
Bridge, State and Strategy
When looking at the UML structure of these three patterns, they look essentially the same. However, they have quite different purposes so the easiest way to distinguish them is probably to look at the context in which they are used and what purpose they serve:
- Bridge: This is a structural pattern that combines different implementations and abstractions so they can vary independently.
- State: The purpose of this pattern is to make the behavior of an object change as its state changes. State-specific requests are passed on to the current state of the object.
- Strategy: Rather than specifying behavior for a particular object state, Strategy defines a family of algorithms that can be varied at runtime.
A good description of the differences can be found on the Strategy page.
Composite and Decorator
These patterns may look quite similar at first sight but when you look at their purposes more closely they are not too hard to distinguish:
- Composite: This pattern is useful for building up an object structure where some parts can contain other parts but they should all be treated the same way.
- Decorator: This pattern is used to add responsibility to an object at runtime so its behavior can vary but is not intended for object aggregation as Composite is.
Composite and Interpreter
Interpreter is a specific implementation of the Composite pattern that is only applicable in the context of languages that need to be interpreted. The composite pattern is used to combine terminals and non-terminals into expressions that can be interpreted.
