Structural model (ii) decorative patterns (Decorator Pattern)

Motivation (Motivate)

How to make "extension object functions" can be dynamic (ie runtime) to achieve needed? While avoiding the "extended functionality to increase," sub-class expansion problems caused? So that the impact of any "functional expansion and change" caused by reduced to a minimum?

Intent (Intent)

To an object dynamically add some additional responsibilities. For increased functionality, Decorator pattern is more flexible than a subclass. - "Design Patterns" GoF

FIG structure (Structure)

Composition mode

Various roles in the decorative pattern are:
(1), abstract component character (the Component) : given an abstract interface to regulate ready to receive additional responsibilities.
(2), the role of specific components (the Component Concrete) : The definition of a class to receive additional responsibilities.
(3), decorative role (the Decorator) : holding a component (Component) instance of the object, and a consistent interface to interface with the abstract member.
(4) Specific decorative role (Concrete Decorator): responsible for component object is added on additional responsibilities.

application:

///  <Summary> 
/// This abstract class is the abstract interface defined in the house, which is equivalent to type Component type, is dumplings, to be decorated, to be packaged
 ///  </ Summary> 
public  abstract  class House 
{ 
    public  abstract  void renovation (); // house decoration method - and this corresponds to the type of Component operation method 
} 

///  <Summary> 
/// this abstract class that defines the interface decoration, which is equivalent to type type Decorator If required specific function, this type can subclass
 ///  </ Summary> 
public  abstract  class DecorationStrategy: House // key bis reflected relationship is-a, that have this relationship, the class may be decorated continue decorated 
{
     // reference Decorator type by combination, to increase the specific embodiment of this type is one of the key features of this point, the inclusion relation, embodied a-Has 
    protected_House House; 

    protected DecorationStrategy (House House) // by the constructors injection, platform initialization 
    {
         the this ._house = House; 
    } 

    public  the override  void Renovation ()    // This method is equivalent to the type of Operation method Decorator 
    {
         IF ( the this . ! _house = null ) 
        { 
            the this ._house.Renovation (); 
        } 
    } 
} 

///  <the Summary> 
/// PatrickLiu house, I will press my request to do a house, equivalent to ConcreteComponent type, this is our specific dumplings stuffing, I personally prefer the leek stuffing
 ///  </ the Summary> 
public Sealed  class the MyHouse: House 
{ 
    public  the override  void Renovation () 
    { 
        Console.WriteLine ( " decoration PatrickLiu house " ); 
    } 
} 

///  <Summary> 
/// apparatus having security functions, monitoring and alarm functions may be provided, rather in ConcreteDecoratorA type
 ///  </ Summary> 
public  Sealed  class HouseSecurityDecorator: DecorationStrategy 
{ 
    public HouseSecurityDecorator (House House): Base (House) {} 

    public  the override  void Renovation () 
    { 
        Base.Renovation (); 
        Console.WriteLine ( " increased safety system " ); 
    } 
} 

///  <Summary> 
/// having insulation material interface, provides thermal insulation function, corresponding to ConcreteDecoratorB type
 ///  </ Summary> 
public  Sealed  class KeepWarmDecorator: DecorationStrategy 
{ 
    public KeepWarmDecorator (House House): Base (House) {} 

    public  the override  void Renovation () 
    { 
        Base .Renovation (); 
        Console.WriteLine ( " increasing insulation function " ); 
    } 
} 

public class Program 
{ 
    static  void Main () 
    { 

        House myselfHouse = new new MyHouse (); // This is our dumplings, need to decorate the house 

        DecorationStrategy securityHouse = new new HouseSecurityDecorator (myselfHouse); 
        securityHouse.Renovation (); 
        // house there a security system 

        // if I have to warm both the security system does, continue to decorate on the line 
        DecorationStrategy securityAndWarmHouse = new new HouseSecurityDecorator (securityHouse); 
        securityAndWarmHouse.Renovation (); 
    } 
}

Highlights realize decorative pattern:

1. By using a combination of techniques, not inherited, the Decorator pattern to achieve the functionality to dynamically grow objects at runtime, and a plurality of extensions may function as desired. Avoiding the use of separate inheritance to give the "inflexible" and "multi subclass ramifications."
2. Component class act as an interface in the abstract Decorator mode, should not be to achieve a specific behavior. And Decorator class for the Component class should be transparent - in other words the Component class without knowing the Decorator class, Decorator class is to extend the functionality of the Component class from the outside.
3. Decorator class appear inheritance relationship is-a Component, i.e. Decorator class inherits the Component class has an interface on the interface. But in relation implemented as a combination of performance and has-a Component, i.e. Decorator turn uses another Component class. We can use one or more Decorator objects to "decorate" a Component object, and the object after the decoration is still a Component object.
4. Decorator pattern does not solve the "multi subclass derived multiple inheritance" problems, the gist of Decorator mode application is to solve the "principal class extension in multiple directions" - for "decorative" means.
   

Decorative pattern of advantages:

1. Decouple the abstract interface from its implementation.
2. Abstract and can achieve independence extension will not affect each other.
3. Implementation details transparent to the client, to be used to hide specific implementation details.
   

Decorative pattern of shortcomings:

1. It increases the complexity of the system
   

Bridge mode should be used in the following situations:

1. If a system needs to add more flexibility between abstract and concrete role members of the role, to avoid static build links between the two levels.
2. Design requirements to achieve any change should not affect the role of the client, or effect a change of the role of the client is completely transparent.
3. We need to cross the graphics and windowing system for multiple platforms.
4. A class changes exist two independent dimensions, and the two dimensions need to be extended.
   

Fourth, implement .NET decorative pattern

    In the Net framework, there is a type of obvious use of the "decorative pattern", this type is Stream. Stream type is an abstract interface that namespace inside the System.IO, it is actually Component. FileStream, NetworkStream, MemoryStream is the entity class ConcreteComponent. BufferedStream the right, CryptoStream decorative objects, which are inherited Stream interface.

   Figure:

    Stream is equivalent to Component, the definition of decorative objects, FileStream is to decorate objects, BufferedStream decorative objects. We look at the definition BufferedStream, partially defined.

public sealed class BufferedStream : Stream
 {
    private const int _DefaultBufferSize = 4096; 
    private Stream _stream;
}