Similar patterns and how to tell them apart
JaninaVoigt (Talk | contribs) (→Facade and Mediator) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Mujtaba Alshakhouri) |
||
| (13 intermediate revisions by 4 users not shown) | |||
| 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. | ||
| + | |||
| + | == 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. | ||
| + | |||
| + | == Prototype and Abstract Factory == | ||
| + | |||
| + | These patterns are both used for creating new objects but they do this in a slightly different way. [[Abstract Factory]] creates completely new objects from scratch, while [[Prototype]] simply copies prototype objects it already has. Look for a clone() or copy() method to identify Prototype. Abstract factory on the other hand has methods for instantiating several different objects from one family of products. | ||
| + | |||
| + | == Abstract Factory and Builder == | ||
| + | |||
| + | Again, both of these patterns are used for creating objects but they have fairly distinct purposes: | ||
| + | |||
| + | * [[Builder]]: This pattern is often used to build up a complex object or object structure from a number of parts. The creation process usually happens in a number of different steps. Look for methods such as addPart() and the getResult() method that returns the final product. | ||
| + | |||
| + | * [[Abstract Factory]]: This pattern is used to build objects from a family of products. Each of these objects is usually built separately unlike when using builder which often builds a single complex object. There is one concrete factory per product family which can usually build several different products from that particular family. To identify this pattern, look for different product families, each of which is created by a separate factory. | ||
| + | |||
| + | ==Abstract Factory and Factory Method == | ||
| + | |||
| + | These patterns are again both used to create objects. They are quite similar; in fact a [[Factory Method]] is often used to implement an [[Abstract Factory]]. The important distinction is that abstract factory is used to construct families of products, where there is one concrete factory for each product family. | ||
| + | |||
| + | == See Also == | ||
| + | * [[Design patterns]] | ||
| + | * [[Combining design patterns]] | ||
Latest revision as of 03:10, 25 November 2010
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.
Prototype and Abstract Factory
These patterns are both used for creating new objects but they do this in a slightly different way. Abstract Factory creates completely new objects from scratch, while Prototype simply copies prototype objects it already has. Look for a clone() or copy() method to identify Prototype. Abstract factory on the other hand has methods for instantiating several different objects from one family of products.
Abstract Factory and Builder
Again, both of these patterns are used for creating objects but they have fairly distinct purposes:
- Builder: This pattern is often used to build up a complex object or object structure from a number of parts. The creation process usually happens in a number of different steps. Look for methods such as addPart() and the getResult() method that returns the final product.
- Abstract Factory: This pattern is used to build objects from a family of products. Each of these objects is usually built separately unlike when using builder which often builds a single complex object. There is one concrete factory per product family which can usually build several different products from that particular family. To identify this pattern, look for different product families, each of which is created by a separate factory.
Abstract Factory and Factory Method
These patterns are again both used to create objects. They are quite similar; in fact a Factory Method is often used to implement an Abstract Factory. The important distinction is that abstract factory is used to construct families of products, where there is one concrete factory for each product family.
