(c) Decorative mode (Decorator)

Decorative Mode (Decorator) is to dynamically add some additional responsibilities to an object, and in addition, the decoration mode is more flexible than the generation of subclasses.

The structure diagram is as follows:

Component is to define an object interface that can dynamically add responsibility to these objects. Concretecomponent is to define a specific object, or to add some responsibility to the object. Decorator decorative abstract class, inherited the component, from the outer class to extend the function of component class, but for component, there is no need to know the existence of decorator. Concretedecorator is the specific decorative object, played to the component to add responsibility functions.

Below is I use C language code implementation, if wrong please point out, lest astray!!!

classcomponent{ Public:    Virtual voidoperation () {printf ("Component operation\n"); }};classConcretecompoent: Publiccomponent{ Public:    voidoperation () {printf ("concretecomponent operation\n"); }};classDecorator: Publiccomponent{protected: Component*component; Public: Decorator () { This->component =nullptr; }    ~Decorator () {Deletecomponent; }    voidSetComponent (component*com) {        if(Component = =nullptr) This->component =com; }    voidoperation () {component-operation (); }};classConcretedecoratora: Publicdecorator{Private:    stringAddedstate;//This class has functions to differentiate Concretedecoratorb Public:    voidoperation () {component::operation (); Addedstate="New State"; printf ("the operation of the specific decorative object a \ n"); }};classConcretedecoratorb: Publicdecorator{Private:    stringAddedstate;//This class has functions to differentiate Concretedecoratorb Public:    voidoperation () {component::operation ();    Addedbehavior (); }    voidAddedbehavior () {//There are methods in this class to distinguish it from Concretedecoratoraprintf"the operation of the specific decorative object b \ n"); }};//ClientvoidMainvoid) {concretecompoent* com =Newconcretecompoent; Concretedecoratora*coma =NewConcretedecoratora; Concretedecoratorb*comb =NewConcretedecoratorb; ComA-setcomponent (COM); Comb-setcomponent (ComA); Comb-operation ();
Delete com;
Delete ComA;
Delete comb;
}

The adornment mode uses the SetComponent to wrap the object, so that the implementation of each adornment object is separated from the use of the object, and each decorator only cares about its own function, and does not need to be concerned about how it is added to the object chain.

If there is only one concretecomponent class and no abstract Componet class, then the decorator class can be a subclass of Concretecomponent. Similarly, if there is only one Concretedecorator class, then there is no need to create a separate decorator class, and you can combine the responsibilities of decorator and Concretedecorator into a single class.

The following is the "Big talk design pattern" above the "side dress date mm" example in C + + implementation:

classperson{Private:    stringname; Public: Person () {} person (stringname) {         This->name =name; }    Virtual voidShow () {cout<< name <<"the Dress up:"; }};classFinery: Publicperson{protected: person*component; Public: Finery () {}voidDecorate (Person *com) {         This->component =com; Component-Show (); }    voidShow () {}};classTshirts: Publicfinery{ Public:    voidShow () {cout<<"T-shirts"; }};classTrouser: Publicfinery{ Public: Trouser () {}voidShow () {cout<<"Cross-Library"; }};classSneakers: Publicfinery{ Public:    voidShow () {cout<<"Sneakers"; }};classSuit: Publicfinery{ Public:    voidShow () {cout<<"Suits"; }};classTie: Publicfinery{ Public:    voidShow () {cout<<"Tie"; }};classLeathershoes: Publicfinery{ Public:    voidShow () {cout<<"Leather Shoes"; }};//ClientvoidMainvoid) { person*p =NewPerson ("Side Dishes"); Sneakers*snekers =Newsneakers (); Trouser*trouser =Newtrouser (); Tshirts*shirt =Newtshirts (); Snekers-decorate (p); Trouser-decorate (snekers); Shirt-decorate (trouser); Shirt-Show (); Deletep; Deletesnekers; DeleteTrouser; Deleteshirt;}

Decorating mode is a way to dynamically add more functionality to an existing feature. When new functionality is required, new code is added to the old class, which usually decorates the core duties or main behaviors of the original class, adds new fields, new methods and new logic to the main class, and increases the complexity of the main class. And these new things are just to meet the needs of some particular behavior that will only be performed in certain circumstances. The decorating mode offers a very good solution, which puts each function to be decorated in a separate class and lets the class wrap the object it is decorating, so that when special behavior needs to be performed, the client code can selectively and sequentially use the adornment function to wrap the object at run time.

The advantages of decorating mode: Removing the decoration function from the class can simplify the original class, effectively distinguish the core functions of the class from the decoration function, and can remove the repetitive decoration logic in the related class.

(c) Decorative mode (Decorator)