Decorator mode for design mode (JAVA) II

The last time I said briefly what is the decorator mode and some of the characteristics of the decorator mode, this time to say the application of decorator mode.

　　first , the main participation of the class or interface

1.component: A class that the decorator and the decorated person inherit together, defines the method that the decorator and the decorator need to implement, can be used alone, or can be wrapped up by the decorator.

2.concreteComponent: An object that lets decorators add functionality to themselves, that is, objects that are eventually modified, or objects that require dynamic addition of new behavior.

3.Decorator: Is a class with a specific decorative function, used to decorate the decorator, can be an abstract class can also be an interface, is the interface that all decorators implement together.

Second, decorator pattern implementation of the legend

　　

This oneself drawing ability limited does not own the drawing, this is from http://www.cnblogs.com/god_bless_you/archive/2010/06/10/1755212.html cut over a decorator pattern realizes the legend,

On the way to the component given is interface, in fact, abstract class is also possible; In addition, a decorator can be decorated by a number of decorators, so the bottom of the graph of the Concretedecorator next to can add a

Decorator1 to decorate Concretedecorator, of course Decorator1 also to inherit component.

iii. Application of examples

　Today the weather is good, we make an ice cream, first need a component, the code is as follows:

　　

/***/publicabstractclass  icecream        {public  abstractvoid  makeicecream ();}

Then there is a concretecomponent, which is the decorator, the code is as follows:

 Public class extends icecream{    @Override    publicvoid  Makeicecream () {        System.out.println ( "Make an ice cream");}    }

With the decorator, here is the decorator, the first is decorator, the code is as follows:

 Public Abstract class extends icecream{    @Override    publicabstractvoid  Makeicecream ( );    }

Then is Concretedecorator, of course concretedecorator need to inherit common decorator, below is two concretedecorator:

 Public class extends decoraticecream{    icecream icecream;          Public Fruiticecream (icecream icecream) {        this. icecream= icecream;    }    @Override    publicvoid  Makeicecream () {        this. Icecream.makeicecream ();        System.out.println ("added fruit");}    }

 Public class extends decoraticecream{    icecream icecream;          Public Chocolateicecream (icecream icecream) {        this. icecream= icecream;    }    @Override    publicvoid  Makeicecream () {        this. Icecream.makeicecream ();        System.out.println ("added chocolate");}            }

Down we can test it:

 Public Static voidMain (string[] args) {System.out.println ("Test decorator mode ..... "); /*** Tested by decorators-can be used alone*/icecream IC=NewMakeicecream ();        Ic.makeicecream (); System.out.println (""); /*** Add only one decorator*/Decoraticecream DiC=Newfruiticecream (IC); System.out.println ("Testing individual decorators begins ... ");        Dic.makeicecream (); System.out.println ("Test single decorator End ... "); System.out.println (""); /*** Test Add multiple decorators*/Decoraticecream Dic1=NewChocolateicecream (Newfruiticecream (IC)); System.out.println ("Test multiple decorators start ... ");        Dic1.makeicecream (); System.out.println ("Test multiple decorators start ... "); System.out.println (""); }

The results of the operation are as follows:

By the result we can see that the individual component is also working, and that using decorators to wrap the component is also handy, and the decorator can be more than one.

　　

　　Four, simplified mode

　　1. What happens when there is only one concretedecorator, such as when my factory only produces fruit ice cream?

The Concretedecorator and decorator can be merged at this time, and the following model diagram is shown below (the source of the image is understood):

　　　　

Here is the test class:

 Public Interface Component {        publicvoid  makeicecream ();}

 Public class Implements component{    publicvoid  Makeicecream () {        System.out.println ( "Make an ice cream");}    }

There is no change in the class of the modifier, the modifier class changes is not big bar, the following code:

 Public class Implements component{    Component Component;          Public Decorator (Component Component) {        this. component=Component;    }       Public void Makeicecream () {        component.makeicecream ();        System.out.println ("added Cream");}    }

Originally to produce fruit ice cream, but accidentally produced into cream, we will eat it. Because only one production, so decorator do not need to inherit the other classes, directly two. Test the code below:

 Public classMain { Public Static voidMain (string[] args) {/*** Test Component*/Component C=Newconcretecomponent ();        C.makeicecream (); System.out.println (""); /*** After merging concretedecorator and decorator*/Decorator D=NewDecorator (c);        D.makeicecream (); System.out.println (""); }}

Operation Result:

2. Another simplification pattern is that there is only one concrete Component class without an abstract Component interface, which allows decorator to inherit concrete Component. The model is as follows:

This is actually very well understood, said two kinds of products can be produced, such as the production of ice cream, but also the production of ice cream, but this time I directly on the production of soda, so do not need

Abstract component Interface, example I will not write, in fact, is very simple.

　Five, the decorator pattern application case

1. There is a need to extend the functionality of a class, or to add additional responsibilities to this class.

2. Adding functionality to a class can be dynamic, not static, and will be dynamic when the additional functionality is canceled.

3. To attach multiple functions to a class, these functions are appended by the form of permutations and combinations, when attaching with inheritance, it is necessary to produce a large number of subclasses, or the function of permutation and combination can not be realized by means of inheritance;

　　

Vi. Advantages and Disadvantages

1. The extension of the object's functionality is more flexible than inheritance, but the increase in flexibility while the complexity is increasing;

2. Designers can create a combination of many different behaviors by using different decorative classes and arranging combinations of these decorations. But decorators can lead to many small classes in the design, which can complicate the program if overused.

3. The adornment mode is programmed for the abstract component (Component) type. However, if you are programming for a specific component, you should rethink your application architecture and whether the decorator is appropriate. Of course, you can change the component interface, add new public behavior, and realize the "translucent" decorator pattern.

Vii. Principles of Design

　　 1. Multi-use combination, less inheritance. The behavior of using inheritance design subclasses is statically determined at compile time, and all subclasses inherit the same behavior. However, if you can extend the behavior of an object with a combination of practices, you can dynamically extend it at run time. 2. Classes should be designed to be open to extensions and closed for modification. For the time being, there will be new problems in the application before you continue to write.

　

　　

Decorator mode for design mode (JAVA) II