Similar patterns and how to tell them apart
From CSSEMediaWiki
(Difference between revisions)
JaninaVoigt (Talk | contribs) (→Facade and Mediator) |
JaninaVoigt (Talk | contribs) |
||
| Line 7: | Line 7: | ||
* 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. | * 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. | * 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. | ||
Revision as of 00:39, 27 September 2009
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.
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.
