Decorator mode (Decorator pattern) for design pattern (structural type)

PS One sentence: Eventually choose Csdn to organize the publication of the knowledge points of these years, the article parallel migration to CSDN. Because CSDN also support markdown grammar, Ah!

"Craftsman Joshui Http://blog.csdn.net/yanbober" read the previous "design pattern (structural type) combination mode (Composite pattern)" http://blog.csdn.net/yanbober/ article/details/45392513

Overview

Decoration mode adds additional new behavior to an object without changing the functionality of an object itself. Decoration mode is a technique used to replace inheritance, which dynamically adds responsibility to an object without having to define a subclass, and uses an association relationship between objects to replace the inheritance relationship between classes. Decoration class is introduced in the decoration mode, which can call the method of the original class to be decorated and add new method to extend the function of the original class.

Core

concept: to dynamically add additional responsibilities to an object, the adornment pattern is more flexible than the subclass implementation in terms of adding object functionality. Decorative mode is an object-structured pattern.

key: decorator Mode structure important core module:

Component (abstract component)

It is the common parent class of concrete component and abstract adornment class, declares the business method implemented in the concrete component, its introduction can enable the client to deal with the object that is not decorated and the object after decoration in a consistent way, realizes the client's transparent operation.

Concretecomponent (Concrete components)

It is a subclass of the abstract component class that defines the concrete artifact object, implements the method declared in the abstract artifact, and the adorner can add additional responsibilities (methods) to it.

Decorator (Abstract decoration Class)

It is also a subclass of the abstract component class, which is used to add responsibilities to specific components, but the specific responsibilities are implemented in their subclasses. It maintains a reference to an abstract artifact object that can invoke the method of decorating the previous artifact object and extend the method through its subclasses to achieve the purpose of decorating.

Concretedecorator (Concrete decoration Class)

It is a subclass of an abstract adornment class that is responsible for adding new responsibilities to the component. Each specific adornment class defines some new behaviors that can invoke methods defined in the abstract adornment class, and can add new methods to augment the behavior of the object.

Note: The decorator mode needs to be aware of the following issues when using:

• Try to keep the interface of the decoration class the same as the interface of the decorated class, so that for the client, either the object before the decoration or the object after the decoration can be treated consistently. This means that, where possible, we should try to use transparent decorative mode.

• Try to keep the concrete decoration class is a "light" class, that is to say, do not put too much behavior in the concrete component class, we can extend it through the decoration class.

• If there is only one concrete component class, then the abstract adornment class can be used as a direct subclass of the concrete component class.

Usage Scenarios

Add responsibilities to a single object in a dynamic, transparent manner without affecting other objects.

Decorative mode can be used when the system cannot be extended in an inherited way or inherited is not conducive to system expansion and maintenance.

There is a large number of independent extensions in the system that cannot be inherited, and to support the combination of each extension or extension will result in a large number of subclasses, resulting in an explosive increase in the number of subclasses; The class is defined as not being inherited (such as the final Class).

Program Ape Instance

It also illustrates the decorator pattern in the case of a bitter-forcing program ape. Given that there are two programmers who will only have their own skills, and now need to make the Android ape have design pattern skills, then decorate him. Implemented as follows:

 PackageYanbober.github.io;//component (abstract component)Interface Programmonkey {voidSkills ();}//concretecomponent (concrete components)Class Androidprogrammonkey implements Programmonkey {@Override     Public void Skills() {System.out.println ("will write Android code!" "); }}//concretecomponent (concrete components)Class Phpprogrammonkey implements Programmonkey {@Override     Public void Skills() {System.out.println ("will write PHP code!" "); }}//decorator (Abstract decoration Class)Class Programmonkeydecorator implements Programmonkey {protectedProgrammonkey Mprogrammonkey; Public Programmonkeydecorator(Programmonkey Mprogrammonkey) { This. Mprogrammonkey = Mprogrammonkey; } Public void Skills() {mprogrammonkey.skills (); }}//concretedecorator (Concrete decoration Class)Class Patterndecorator extends Programmonkeydecorator { Public Patterndecorator(Programmonkey Mprogrammonkey) {Super(Mprogrammonkey); }@Override     Public void Skills() {Super. Skills (); System.out.println ("will design the pattern!" "); }} Public  class Main {     Public Static void Main(string[] args) {//Have an Android program ape will only write Android codeProgrammonkey Programmonkey =NewAndroidprogrammonkey (); Programmonkey.skills ();//Decorate him, put on the force of skills, he unexpectedly besides writing Android also understand design modeProgrammonkey =NewPatterndecorator (Programmonkey);        Programmonkey.skills (); Programmonkey =NewPhpprogrammonkey ();    Programmonkey.skills (); }}

sum up a

The advantages of decorating mode are as follows:

• For extending the functionality of an object, the adornment mode is more flexible than inheritance and does not result in a dramatic increase in the number of classes.
• Different kinds of decorative classes can be selected at run time in a dynamic way, thus implementing various behaviors.
• An object can be decorated many times, by using different decorative classes and the arrangement of these decorative classes, you can create a lot of different behavior of the combination, to get more powerful objects.
• The concrete component class and the concrete adornment class can change independently, the user may add the new concrete component class and the concrete adornment class according to the need, the original class library code does not need to change, conforms to "the opening and closing principle".

The disadvantages of decorating mode are as follows:

• Using the decorative mode for system design will produce a lot of small objects, the difference is that they are connected to each other in a different way, rather than their class or property values are different, a large number of small objects will inevitably occupy more system resources, on a certain program to affect the performance of the program.
• Decoration mode provides a more flexible solution than inheritance, but also means more error-prone than inheritance, troubleshooting is also very difficult, for many decorative objects, debugging may need to search for errors in the step-by-step troubleshooting, more cumbersome.

"Craftsman Joshui Http://blog.csdn.net/yanbober" Continue reading "to be continued ... 》

Decorator mode (Decorator pattern) for design pattern (structural type)