Design Pattern 09:decorator Decorative mode (structural mode)

Decorator Decorative Mode (structural mode)

Subclass complex sub-class, how many subclasses
Join us we need to develop a tank for the game, in addition to different models of tanks, we also want to add a variety of features in different situations: such as infrared night vision function, such as water amphibious function, such as satellite positioning function and so on.

Problem code:

    /// <summary>    /// Abstract Tank     /// </summary>     Public Abstract class Tank    {        publicabstractvoid  Shot ();          Public Abstract void Run ();    }

    //various models     Public classT50:tank { Public Override voidShot () {//...        }         Public Override voidRun () {//...        }    }     Public classT75:tank { Public Override voidShot () {//...        }         Public Override voidRun () {//...        }    }

    /// <summary>    ///Infrared Night Vision/// </summary>     Public InterfaceIA {//...     }    /// <summary>    /// Amphibious/// </summary>     Public InterfaceIB {//... }

    // A variety of different function combinations     Public class T50a:t50, IA    {        //...     }        publicclass  t50b:t50, IB    {        //  ...     }    publicclass  t50ab:t50,ia,ib    {        // ...    }

Motive (motivation)
The problem described above is rooted in our "excessive use of inheritance to extend the functionality of objects", because of the static traits introduced into the class, which makes this extension inflexible, and as the number of subclasses increases (the expansion function increases), the combination of each seed class (the combination of extended functions) causes more subclasses to swell (multiple inheritance).

How do you enable the expansion of object functionality to be implemented dynamically (at runtime) as needed? At the same time, avoid the problem of sub-class expansion caused by "expanded function". So that the impact of any "functional expansion change" is reduced to a minimum?

Intentions (Intent)

Add some additional responsibilities to an object dynamically. In terms of increased functionality, the decorator mode is more flexible than generating subclasses. --"actual mode" GoF

Instance code:

    /// <summary>    /// Abstract Tank     /// </summary>     Public Abstract class Tank    {        publicabstractvoid  Shot ();          Public Abstract void Run ();    }

   //various models     Public classT50:tank { Public Override voidShot () {//...        }         Public Override voidRun () {//...        }    }     Public classT75:tank { Public Override voidShot () {//...        }         Public Override voidRun () {//...        }    }

     Public Abstract classDecorator:tank//interface inheritance, abstract classes can be seen as interfaces    {        PrivateTank Tank;//Has-a Object Combination         PublicDecorator (Tank Tank) { This. Tank =tank; }         Public Override voidShot () {tank.        Shot (); }         Public Override voidRun () {tank.        Run (); }    }

    /// <summary>    ///infrared Function Extension/// </summary>     Public classDecoratora:decorator { PublicDecoratora (Tank Tank):Base(tank) {}Public Override voidShot () {//infrared Function Extension//Do shot ...            Base.        Shot (); }        Public Override voidRun () {//infrared Function Extension//Do run ...            Base.        Run (); }    }

    /// <summary>    ///Amphibious function Expansion/// </summary>     Public classDecoratorb:decorator { PublicDecoratorb (Tank Tank):Base(tank) {}Public Override voidShot () {//Amphibious function Expansion//Do shot ...            Base.        Shot (); }        Public Override voidRun () {//Amphibious function Expansion//Do run ...            Base.        Run (); }    }

    class App    {        publicstaticvoid  Main ()        {            Tank Tank=new  T50 ();             New Decoratora (tank); // infrared function extension             New Decoratorb (DA); //  expansion of infrared and amphibious functions         }    }

Several points of decorator model

• By adopting a combination rather than an inherited approach, the decorator pattern enables the ability to dynamically extend the functionality of the object at run time, and can extend multiple functions as needed. Avoids the "poor flexibility" and "multi-subclass derivation problems" that are created by using inheritance alone.
• The Tank class acts as an abstract interface in decorator mode and should not implement specific behavior. And the decorator class should be transparent to the tank class--in other words, the tank class does not need to know that the Decorator,decorator class is external to extend the tank class functionality.
• The Decorator class behaves as an inheritance of the Is-a tank class on the interface, that is, decorator inherits the interfaces that the tank class has. In the implementation, it also shows the combination of has-a tank, that is, the decorator class uses another tank class. We can "decorate" a tank object with one or more decorator objects, and the decorated object remains the tank object.
• Decorator mode is not to solve the problem of "multiple inheritance of multiple subclasses", the main point of application of decorator mode is to solve "the extension function of principal class in multiple directions"--meaning of "adornment".

Design Pattern 09:decorator Decorative mode (structural mode)