Design Patterns-Decorator/strategy/Observer patterns

Decorator mode

Decorator Mode: A simple understanding is to wrap a layer of attachment action on the original object, and keep the wrapped object in the same class family as the wrapper, but add additional actions specific to the wrapper class.

The key points are:

1. Wrapper class object has-a to be wrapped;
2. The wrapper class and the wrapped object belong to the same class family, which all have the same super type;
3. Packaging can be nested/can be packaged multiple times, that is, the packaging of a wrapper after the packaging of a package of the resulting object can also continue to be packaged in other packaging, including the previous layer of packaging Class A

The packaging model embodies the principle of "open to expansion, close to modification":

1. Open to extensions: by wrapping, the original wrapped object has the extended behavior specified by the wrapper class, which can be used in the case of the original wrapped object (assuming, of course, that is the code based on the interface design)
2. Closed for modification: You can extend the functionality without modifying the existing code.

The difference between using wrapper mode and using inheritance: Using wrapper mode to dynamically add behavior, using inheritance is static and is determined at compile time. Assuming that the inheritance pattern is used, you must write a special class for each possible combination of behaviors, that is, the kind of behavior that your code can represent is determined by the class you are designing, and the customer cannot get a combination of patterns outside of your design, and with the wrapper pattern, you simply write all possible basic behaviors, And how these behaviors are combined is entirely up to the customer to decide on their own needs.

Disadvantages of the Decorator model:

1. May join a large number of small classes or have many objects;
2. For some code that is dependent on a particular type, the wrapper is invalidated.

Class Model:

Policy mode

Policy mode: Define the algorithm family, encapsulate each other, so that they can be replaced with each other, so that the algorithm changes independently of the customer code using the algorithm. The purpose of its departure is: Package changed parts!

Points:

1. Define multiple algorithms, i.e. multiple implementation scenarios;
2. Each algorithm can be replaced, the general implementation is to let all the algorithm implementation of an interface, and in the customer code for the interface programming;
3. The algorithm changes independently of the user: You can change the implementation code of the algorithm, but the user code does not have any changes; You can set the specific implementation algorithm used by the consumer

Use case: If you define a coder class, different coder have different writebolg ways, then according to the strategy model, its class model is as follows: You can also add a set (Writeblog) method to the coder to dynamically set the policy

Advantage: If there is such a demand: There are codera,coderb,coderc,coderd four kinds of coder, of which a B uses Incnblog,c,d incsdn, then if the use of inheritance to solve, then you may need to Codera, The Incnblog rewrite of the writeblog in the Coderb, incsdn in the Coderc,coderd, apparently produced duplicate code. Furthermore, when the implementation of INCSDN is changed later, it needs to be maintained in the CD two classes. Further, if Coderb suddenly want to write a blog in incsdn Way, the way of inheritance may be difficult to cope with. And the use of policy mode can be a good solution to these problems.

Observer pattern

Observer pattern: Defines a one-to-many dependency between objects, and when an object changes state, all its dependents are notified and updated automatically.

Points:

1. One-to-many: avoid multiple objects controlling the same data
2. Can be registered to remove: To minimize the coupling between the observer and the Observer

A simple observer model:

1. There are two ways to update a message. One is pull, that is, call the GetData method in the Oberver to get the data you want, convenient on demand, one is push, that is, in the Update method (at this time the update must have parameters), all data types are passed to Oberver, it is more convenient, is also used in more ways;
2. Why the observer to have a subject reference: Used to remove their own registration;
3. Do not rely on the order in which the observers are notified: since the purpose of our design is loosely coupled, if subject makes some changes that cause the order of the notifications to change, if there is some sort of dependency on the notification order in Obsever, Then observer must also make corresponding changes to adapt to subject changes, which is not in line with the original design
4. In java.util.Observable provide the observer model, http://www.android-doc.com/reference/java/util/Observable.html, things to be aware of, You must call Setchanged () before the notification will be valid, because in the Notifyobservers method, you first check that changed is true to notify Obervers. This design allows for more flexibility in the notification mode, such as the source data data for the weather station, which may be updated in real time, but may be sufficient for the observer to update every hour, so that setchanged () can be called every hour.

Design Patterns-Decorator/strategy/Observer patterns