1. Discussion of structural patterns
We can notice the similarity between the structural patterns, especially the similarities between their participants and collaboration. This may be because a structured model relies on the same small set of language mechanisms to construct code and objects: But inheritance and multiple inheritance mechanisms are used for class-based models, and object composition mechanisms are used for object models. But these similarities obscure the different intentions of these models.
2.Adapter and bridge mode
the adapter model and bridge model have some common characteristics. They all provide a degree of indirection to another object, because it facilitates the flexibility of the system. They all involve forwarding requests to this object from an interface other than themselves.
These patterns differ mainly in their respective uses. The adapter mode is primarily designed to address mismatches between two existing interfaces. He does not consider how these interfaces are implemented, and he does not consider how they might evolve. This approach does not require a redesign of any of the two individually designed classes to enable them to work together. Bridge mode, on the other hand, bridges the abstract interface with its (possibly multiple) implementation parts. While this pattern allows you to modify the class that implements it, he still provides a stable interface for the user. Bridge mode also adapts to the new implementation as the system evolves.
because of these differences, adapter and bridge patterns are often used in different stages of the software life cycle. when you find that two incompatible classes must work at the same time, you must use the adapter mode, which is generally intended to avoid code duplication. The coupling here is not predictable. Instead, the user of bridge must know beforehand that an abstraction will be made up of multiple implementations, and that both abstractions and implementations evolve independently. The adapter mode is implemented after the class has been designed, and bridge mode is implemented before the design class. It does not mean that the adapter model is inferior to bridge mode, just because they are targeting different problems.
You can think of facade as an adapter for another group of objects. But this explanation ignores the fact that facade defines a new interface, while adapter re-uses an existing interface. Remember that the adapter works with two existing interfaces instead of defining a completely new interface.
3.Composite, decorator and proxy
The composite and decorator modes have similar structural diagrams, which means that they all organize a variable number of objects based on a recursive combination. This common denominator may make you think that the decorator object is a degenerate composite, but this point of view does not grasp the decorator model points. Similarities are only for recursive combinations, again, because the two patterns are different in purpose.
Decorator is designed to enable you to add responsibilities to objects without having to generate subclasses. This avoids the static implementation of all functional combinations, resulting in a dramatic increase in subclasses. Composite has different purposes, and it is designed to construct classes, which are multiple related functions that can be handled in a uniform manner, while multiple objects may be treated as an object. It does not focus on decoration but on expression.
Although their purpose is different, they are complementary. So composite and decorator patterns are often used in conjunction, and when designing with these two modes, we don't need to define new classes, just plug some objects together to build the app. At this point the system will have an abstract class, he has some composite subclasses and decorator subclasses, there are some basic building blocks to implement the system. At this point, composite and decorator will have a common interface. From the perspective of Decorator mode, composite is a concregecomponent. From the composite model point of view, decorator is a leaf.
Another pattern similar to the structure of the decorator pattern is proxy. Both of these modes describe how to provide some indirect reference to an object, and the implementation portion of the proxy and decorator objects preserves pointers to another object, which sends requests to the object. But again, they have different design goals.
Like the decorator mode, the proxy schema is built into an object that provides a consistent interface to the user. However, unlike the decorator model, the proxy mode cannot be dynamically added or detached, nor is it designed for recursive combinations. The purpose of this is to provide a substitute for an entity when it is inconvenient or non-compliant, for example, if the entity is on a remote device, access is restricted, or the entity is persisted.
In Porxy mode, an entity defines a key function, and a proxy provides (or denies) access to it. In decorator mode, the component only provides some functionality, while one or more deocorator is responsible for completing other functions. The decorator mode is suitable for situations where the full functionality of an object cannot be determined at compile time. This openness makes recursive grouping an essential part of the decorator model. This is not the case in proxy mode, because the proxy pattern emphasizes a relationship (proxy and its entity), which can be statically expressed.
This difference between patterns is important because they address some of the specific, recurring problems of the object-oriented design process. But this does not mean that these patterns cannot be used in combination. You can imagine a proxy-decorator that can add functionality to a proxy, or a decorator-proxy to decorate a remote object.
Reference:
Http://openhome.cc/Gossip/DesignPattern/DecoratorPattern.htm
Http://item.jd.com/10057319.html
http://blog.csdn.net/zhangerqing/article/details/8239539
Structual Design--Summary