Decorative design pattern mode (the Decorator) and code examples Detailed

The definition of a decorative pattern

　　Decorative defined (the Decorator) mode: refers to the object structure without changing the existing situation, the dynamic object is to increase the number of functions (i.e., increase its additional function) mode, which belongs to the object structure schema.

Second, the advantages and disadvantages of decorative patterns

　　The main advantage of decoration (Decorator) mode are:

• Decorated schema extensions objects function more flexible than using inheritance.
• You can design a number of different decorative concrete, creating a combination of several different behaviors.

　　The main disadvantages are:

　　Decorative pattern increased the number of sub-categories, if overused procedures will become very complicated.

Third, to achieve decorative pattern

　　Typically, a class extend functionality will be implemented using inheritance. Inherited but having static features, high coupling, and with the increase of the extension, it expands subclasses. If you use a combination of relationships to create a wrapper object (ie, decorative objects) to wrap the real object, and in keeping the real object without changing class structure, providing additional functionality, which is the goal of decorative patterns. To analyze the following basic structure and implementation.

　　Decorative pattern mainly includes the following roles.

• Abstract component (Component) Roles: define an abstract interface to regulate an object ready to receive additional responsibilities.
• Specific components (Concrete Component) role: to achieve abstract components, add some of its responsibilities by decorative role.
• Abstract decorative (the Decorator) Role: inherit the abstract member, and includes examples of specific member, the specific member function can be extended by its subclasses.
• Specific decoration (ConcreteDecorator) Role: implementation-dependent method abstract decoration, and add additional responsibilities to specific member objects.

　　FIG decorative pattern configuration as shown:

　　　　　　　　　　　　

　　Let's take a look at our new way through inheritance properties of this implementation, such as this example uses pancakes, fruit, code is as follows:

/**
 * Pancakes
 */
public class Battercake {
    protected String getDesc(){
        return "煎饼";
    }
    protected int cost(){
        return 8;
    }
}

/**
 * Pancakes and eggs
 */
public class BattercakeWithEgg extends Battercake {
    @Override
    public String getDesc () {
         return  Super .getDesc () + "add an egg" ;
    }

    @Override
    public int cost() {
        return super.cost()+1;
    }
}

/**
 * Plus plus egg pancake sausage
 */
public class BattercakeWithEggSausage extends BattercakeWithEgg {
    @Override
    public String getDesc () {
         return  Super .getDesc () + "plus a sausage" ;
    }

    @Override
    public int cost() {
        return super.cost()+2;
    }
}

public class Test {
    public static void main(String[] args) {
        Battercake battercake = new Battercake();
        System.out.println (battercake.getDesc () + "sale price:" + battercake.cost ());

        Battercake battercakeWithEgg = new BattercakeWithEgg();
        System.out.println (battercakeWithEgg.getDesc () + "sale price:" + battercakeWithEgg.cost ());

        Battercake battercakeWithEggSausage = new BattercakeWithEggSausage();
        System.out.println (battercakeWithEggSausage.getDesc () + "sale price:" + battercakeWithEggSausage.cost ());
    }
}

　　Finally, the test results:

Pancakes sale price: 8 
pancakes plus an egg sales price: 9 
pancakes plus eggs plus a sausage sale price: 11

　　While we realize the extensions class, but coupled with high inheritance, and if the new class would increase indefinitely, if you modify the original class, a great impact on the back of the class, so if you use decorative patterns, as follows:

public class DecoratorPattern
{
    public static void main(String[] args)
    {
        Component p=new ConcreteComponent();
        p.operation();
        System.out.println("---------------------------------");
        Component d=new ConcreteDecorator(p);
        d.operation();
    }
} 

// abstract component role 
interface   the Component
{
    public void operation();
} 

// specific role member 
class ConcreteComponent the implements the Component
{
    public ConcreteComponent()
    {
        System.out.println ( "Creating the role of specific components" );       
    }   
    public void operation()
    {
        System.out.println ( "method call specific role member Operation ()" );           
    }
} 

// abstract decorative role 
class Decorator the implements the Component
{
    private Component component;   
    public Decorator(Component component)
    {
        this.component=component;
    }   
    public void operation()
    {
        component.operation();
    }
} 

// specific decorative role 
class ConcreteDecorator the extends Decorator
{
    public ConcreteDecorator(Component component)
    {
        super(component);
    }   
    public void operation()
    {
        super.operation();
        addedFunction();
    }
    public void addedFunction()
    {
        System.out.println ( "addedFunction additional features for a particular member role ()" );           
    }
}

Application Scene Four, decorative patterns

　　The structure and characteristics of the foregoing explanation about the decorative pattern, described below its application scenarios, the decorative pattern is generally used in the following situations.

• When it is desired to add additional functions to an existing category, but the method can be expanded to generate subclass. For example, the class is hidden or if the class is the ultimate class or the use of inheritance will produce a lot of sub-categories.
• When it is desired to produce a lot of existing functions through a set of basic functions of permutations and combinations, using inheritance it is difficult to achieve, and the model is very good decorated achieved.
• When the object can dynamically add functional requirements, it may be withdrawn and then dynamically.

　　The most famous application of decorative patterns in the Java language design than the Java I / O standard library of. For example, InputStream subclasses FilterInputStream, OutputStream subclass FilterOutputStream, a subclass of BufferedReader Reader and FilterReader, there Writer subclasses BufferedWriter, FilterWriter and PrintWriter, etc., they are abstract decoration.

　　The following code is an example of decorative BufferedReader FileReader increase the buffer employed:

BufferedReader in=new BufferedReader(new FileReader("filename.txtn));
String s=in.readLine();

V. decorative pattern extend

　　Decorative pattern contained four role is not present at any time, in some environments pattern can be simplified, as the following two cases.

• If a particular member is not only abstract members, inheritance allows Abstract decorative member Specifically, the structure shown in FIG. FIG:

 　　　　　　　　　　　　　　 

•  If only a specific decorative, abstract and concrete decorated decoration may be combined, the structure shown in Figure: