[Design Mode] 9 decorator pattern Decorator

Original link: http://www.cnblogs.com/diegodu/p/4448093.html

Turn: http: //www.jellythink.com/archives/171#prettyPhoto

What is the decorative pattern?

In the GOF's "Design Patterns: Elements of Reusable Object-Oriented Software," a book on decorative pattern had this to say: an object to dynamically add some additional responsibilities. Increases functionally, Decorator pattern compared subclassing more flexible.

The decorative pattern can be dynamically add functionality to the object, it is to add functionality to the object from an external object. Function is generally added to the object, the object is added either directly modify the corresponding function, or a derived subclass corresponding extension, or is object composition manner. Obviously, directly modify the corresponding class in this way is not desirable. In object-oriented design, and we should try to use a combination of an object, not the object inheritance to extend and multiplexing functions. Decorator is a combination of an object-based approach, the object can be very flexible to add the required functionality. Nature decorator pattern is dynamic combination. Dynamic is the means, the combination is the goal. In short, the decorative patterns is simplified by the complex function, decentralization, then during operation, such a pattern as needed dynamic composition. It allows us to add some functionality to an object instead of the entire class.

Component: an object interface definitions, these roles can be added to objects dynamically;

ConcreteComponent: the definition of a particular Component, inherited from Component, override the Component class virtual function;

Decorator: Component object points to maintain a pointer to the object to be decorated the pointer points to the need; and define an interface consistent with the Component Interface;

ConcreteDecorator: Adding functions to the component.

/*
** FileName     : DecoratorPatternDemo
** Author       : Jelly Young
** Date         : 2013/12/19
** Description  : More information, please go to http://www.jellythink.com
*/
#include <iostream>
using namespace std;
class Component
{
public:
     virtual void Operation() = 0;
};
class ConcreteComponent : public Component
{
public:
     void Operation()
     {
          cout<<"I am no decoratored ConcreteComponent"<<endl;
     }
};
class Decorator : public Component
{
public:
     Decorator(Component *pComponent) : m_pComponentObj(pComponent) {}
     void Operation()
     {
          if (m_pComponentObj != NULL)
          {
               m_pComponentObj->Operation();
          }
     }
protected:
     Component *m_pComponentObj;
};
class ConcreteDecoratorA : public Decorator
{
public:
     ConcreteDecoratorA(Component *pDecorator) : Decorator(pDecorator){}
     void Operation()
     {
          AddedBehavior();
          Decorator::Operation();
     }
     void  AddedBehavior()
     {
          cout<<"This is added behavior A."<<endl;
     }
};
class ConcreteDecoratorB : public Decorator
{
public:
     ConcreteDecoratorB(Component *pDecorator) : Decorator(pDecorator){}
     void Operation()
     {
          AddedBehavior();
          Decorator::Operation();
     }
     void  AddedBehavior()
     {
          cout<<"This is added behavior B."<<endl;
     }
};
int main()
{
     Component *pComponentObj = new ConcreteComponent();
     Decorator *pDecoratorAOjb = new ConcreteDecoratorA(pComponentObj);
     pDecoratorAOjb->Operation();
     cout<<"============================================="<<endl;
     Decorator *pDecoratorBOjb = new ConcreteDecoratorB(pComponentObj);
     pDecoratorBOjb->Operation();
     cout<<"============================================="<<endl;
     Decorator *pDecoratorBAOjb = new ConcreteDecoratorB(pDecoratorAOjb);
     pDecoratorBAOjb->Operation();
     cout<<"============================================="<<endl;
     delete pDecoratorBAOjb;
     pDecoratorBAOjb = NULL;
     delete pDecoratorBOjb;
     pDecoratorBOjb = NULL;
     delete pDecoratorAOjb;
     pDecoratorAOjb = NULL;
     delete pComponentObj;
     pComponentObj = NULL;
}

Using the occasion

1. Without affecting other objects, a dynamic, transparent way to add functions to the individual objects;
2. Handle those responsibilities can be undone;
3. The method can not be employed when generating a subclass be expanded. In one case, there may be a large number of separate extension to support each combination will produce a large number of sub-categories, so that the explosive growth in the number of subclasses. Another situation may be hidden because of the class definition, the class or subclass definition can not be used to generate.

Precautions

1. The consistency of the interface; the interface with which it must be decorated decorative objects Component interface is the same, so all of ConcreteDecorator class must have a common parent; so for the user, is a unified interface;
2. Decorator abstract class is omitted; only when a need to add functions, it is not necessary Decorator defining abstract classes. Because we often have to deal with, the existing class hierarchy rather than designing a new system, then you can put forward the request to the Component Decorator duties merge into ConcreteDecorator in;
3. Keep it simple for the Component class; in order to ensure consistency, components and decorative interface must have a common Component class, so keep the simplicity of the Component class is very important, so that the Component class should focus on the defined interfaces instead of storing data. Definition of data representation should be delayed until the child class, otherwise the Component class would become too complex and cumbersome, making it difficult to heavy use. Component class imparting too many features, but also makes some concrete subclasses of their function they do not require increased considerably;

Points achieved

1. Component class in the Decorator pattern act as abstract interface should not be to achieve a specific behavior. Decorator and Component class should be transparent to the type, in other words without having to know the Component class class Decorator, Decorator class is to extend the functionality of the Component class from outside;
2. Decorator class interface on the performance of inheritance "is-a" Component, i.e. Decorator class inherits the Component class has an interface. However, in the realization of the performance of the combination and the relationship "has-a" Component of , 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;
3. Decortor mode is not solve the "multi subclass derived multiple inheritance" problem, Application Notes Decorator pattern is to solve the "principal class extension in multiple directions" - for "decorative" meaning;
4. It can be very flexible to use the Decorator pattern in practice. If only one ConcreteComponent class without abstract Component class, Decorator class is a subclass of ConcreteComponent. If only one ConcreteDecorator class, then there is no need for a separate Decorator class, and can merge Decorator and ConcreteDecorator responsibility as a class.
5. Decorator pattern advantage is to provide more flexible than succession extension, particularly by using different combinations and permutation of these decorative decorative can create a lot of combinations of different behaviors;
6. Due to the use of decorative patterns, you can use inheritance requires less than the number of classes. Using fewer classes, of course, that the design is easy. But, on the other hand, the use of decorative patterns produce more than inheritance of objects. Objects that make troubleshooting more difficult, especially in these objects look very much alike.

The difference between bridge mode

Before summed up the C ++ design patterns - bridge mode ; you will find that both are inherited in order to prevent excessive, resulting in the case of a subclass of flooding. So what is the main difference between the two is it? Bridge mode is defined abstract and implementation of separation (not in combination with the inheritance mode), so that both can be varied independently. You can reduce the growth of the derived class. If the light from this point of view, and decorators similar, but both still have some important differences:

1. Bridge mode said separation, and in fact refers to the separation structure (when the structure and implementation may change) based on the attribute or attributes and behavior separated; the decorator attribute-based merely closed to conduct independent class, so as to achieve its decoration, which is extended. For example: you can use the exception class between the classes and exception handling model to achieve the completion of the bridge, but can not be used to design decorative patterns; if for exception handling needs to be extended, we can add Decorator for exception handling classes to add the decorating process, to expand exception handling, which is a bridging mode and decorative patterns mix;
2. Lateral bridging behavior is behavior are not associated with each other behavior, note that there is no correlation between the behavior here, it is between, say, there is no exceptions and exception handling behavior associated with the same; and Behavior decorator pattern having Stacks of its manifested result is a whole, a result of a combination of various actors.

to sum up

Decorative pattern with emphasis on decoration, decorative effect on the core functionality; the extension inheritance subclasses into class combination of features, so users will need to expand the subclass pass the call to a combination, a combination of how user to user decision. When I study decorative patterns, it is the focus of the analysis of the "decoration" of the word, as we all know, is to add some decorative features on a core subsidiary function, so that the core functions play a greater role, but ultimately it's core function is It can not be lost. It's like when we were windows shell development, we are on the windows of this layer of the shell were decorative features, enabling some of the decorative features we need, but the final function is to complete the windows shell. This is like, our core function is to give decorative add a layer of coat, making it look more beautiful and perfect.

 

Reproduced in: https: //www.cnblogs.com/diegodu/p/4448093.html