Design Pattern-decoration pattern

The purpose of decoration is to add ornaments to the original objects so that the objects can present different characteristics. Of course, in the class design, the decoration mode is used to add new features and behaviors to the class. The structure is as follows:

*
* | ￣ |
* | Component | <----------------------------------------------------------------- |
* | ----------------------- |
* | Operation () |
* | ________________ |
* △ |
* |
* | ￣ |
* | ￣ | ◇-Component ------ |
* | Concreatecomponent | decorator |
* | -------------------------------------- | --------------------------------------- |
* | Operation () ○ ------------- | -- → | component-> operation () |
* | _________________ ___ | ______________________ | _____________________ |
* △
* |
* | ￣ |
* | ￣ |
* | Concreatedecoratora | concreatedecoratorb |
* | -------------------------------------- | --------------------------------------- |
* | Operation () ○ ----------- |-→ | decorator: Operation () |
* | Addedstate | addedbehavior () |
* | _____________________ | ______________________ | _________________ ___ |
*
Role:

Abstract component: provides an abstract interface to standardize the objects to receive additional responsibilities.
Concrete component: defines a class that will receive additional responsibilities.
Decorator: an instance that holds a component object and defines an interface consistent with the abstract Component Interface.
Concrete decorator: attaches an additional responsibility to the component object.

There are two implementation modes for the decoration mode. One is to use the delegate method as shown in, and the other is to use the subclass method, however, in terms of decoration intent, it is better to use the delegate method. The delegated approach can be used dynamically and flexibly to add new responsibilities and functions to objects.

Summary:

A) The decoration mode does not change the original behavior and features of the component, but adds new behaviors and features. Unlike the adapter mode, the decoration only changes the responsibility of the object, not the interface. The adapter mode gives the object a new interface.

B) Although the decoration mode can be regarded as a special case of only one component in the combination mode, the decoration is mainly to add responsibility rather than aggregation ).
C. Both the decoration mode and the rule mode allow you to change objects, but the decoration mode only changes the appearance of objects, while the rule mode changes the interior of objects.

D) new features and behaviors can be added by subclass. However, when more features and behaviors need to be added, the class system will be too large, the decoration mode is a combination of decoration and components, so it is not only flexible, but also can reduce the number of classes. In addition, not all cases can be performed in subclass mode (for example, the specific component is a seal class)

E) The decoration mode is more flexible than static inheritance, and it can avoid having too many features in the class with a higher hierarchy; but the disadvantage is that it will produce many small objects (ornaments ); although decorator inherits from component, it is not the same object as component. Therefore, you should pay special attention to the naming and do not misunderstand it.

F) The decoration mode and bridge mode can be used to reduce the number of classes (if the component itself is not evolved, or the evolution is very simple, the decoration mode cannot have fewer classes, but will increase the number of classes, can avoid complex inheritance structures ,. But there are also the following differences:

1) there is a difference between the two in terms of structure (the comparison graph will know)

2) different implementation methods: the decoration mode separates the core functions of components from the additional functions. The class system changes independently, and the additional functions are handed over to the decoration subclass, in this way, the core functions and additional functions are independent of each other, and the decoration subclass encapsulates components to dynamically provide additional functions for the formation. The bridge mode is to separate the Implementation Details of abstract behaviors, construct an implementation structure, and adapt to changes through the combination of abstract architecture and implementation structure system.

3) In applications, different decorative modes can be used at the same time (for example, border and filter conditions can be added for images. Different implementations in the bridge mode cannot be applied at the same time.

4) decorative parts are independent. The component parts do not use ornaments, while the implementation Part in the bridge mode is relatively independent. The abstract Part must depend on the Implementation part for work.

The decoration mode is also a type of packaging mode.

 

Note: although we do not recommend subclass implementation in the decoration mode, we still need to use this method in practical applications, because the delegate method is used to implement decoration, decoration can only be specific to a certain type of component. It cannot be implemented when we need to decorate some column-type components. Although a large number of decorative classes are added by subclass, and the increase of repeated decorative classes is even greater, these subclasses can be dynamically generated due to dynamic compilation and the use of dynamic intermediate language commands, this provides a possibility for the so-called AOP (Aspect-Oriented Programming. In fact, spring. Net's AOP programming uses the decoration mode and is subclass-based. The reason is very simple. In this scenario, additional responsibilities are required, but the decoration must be consistent with the component interface. The AOP in spring is the use of the decoration mode + dynamic code injection (dynamic compilation or use of emit). Of course, this use is also improved by combining the observer mode, the responsibility class to be attached is injected as the observer. In this way, the decoration class is only the responsibility class to be added for calling according to certain rules, which greatly reduces the number of decoration classes and increases flexibility, however, in this case, the execution logic of the decoration class itself becomes complicated, especially for the processing of the pre-notification. If the pre-notification affects whether or not to actually execute the specific task class responsibility method, it is difficult to choose whether one-vote or one-vote under multiple such pre-notifications, and this mode is not suitable if the specific responsibility class is closely coupled with the notification class. Although the AOP injection in spring.net has been fully considered, the best way to accomplish this cross-cutting goal is to consider it during design, however, we do not have to use the AOP mode if we adopt the virtual mode or other methods. In a word, do not apply a technology to apply a technology.