c++设计模式----装饰模式

前言

　　在实际开发时，你有没有碰到过这种问题；开发一个类，封装了一个对象的核心操做，而这些操做就是客户使用该类时都会去调用的操做；而有一些非核心的操做，可能会使用，也可能不会使用；如今该怎么办呢？

1. 将这些非核心的操做所有放到类中，这样，一个类就包含了不少核心的操做和一些看似有关，可是又无关的操做；这就会使核心类发生“爆炸”的现象，从而使核心类失去了必定的价值，也使使用核心类的客户在核心操做和非核心操做中挣扎；
2. 使用继承来扩展核心类，须要使用核心类时，直接创建核心类对象；当须要使用核心类扩展类时，就创建核心类扩展类对象；这样貌似是一种颇有效的方法；可是因为继承为类型引入的静态特质，使得这种扩展方式缺少灵活性；同时，又掉入了另外一个陷阱，随着扩展功能的增多，子类也会增多，各类子类的组合，就会致使类的膨胀，最后，就会被淹没在类的海洋；此时，也不用我多说，你是否是想起了桥接模式，桥接模式就是为了适应多个维度的变化而发生子类“爆炸”的状况，可是，桥接模式是为了适应抽象和实现的不一样变化，并不适用于我这里说的。那如何是好，这就要说到今天总结的装饰模式了。

什么是装饰模式？

　　装饰模式可以实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。一般给对象添加功能，要么直接修改对象添加相应的功能，要么派生对应的子类来扩展，抑或是使用对象组合的方式。显然，直接修改对应的类这种方式并不可取。在面向对象的设计中，而咱们也应该尽可能使用对象组合，而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式，能够很灵活的给对象添加所须要的功能。装饰器模式的本质就是动态组合。动态是手段，组合才是目的。总之，装饰模式是经过把复杂的功能简单化，分散化，而后再运行期间，根据须要来动态组合的这样一个模式。它使得咱们能够给某个对象而不是整个类添加一些功能。　

UML类图

　　

Component:定义一个对象接口，能够给这些对象动态地添加职责；

ConcreteComponent:定义一个具体的Component，继承自Component，重写了Component类的虚函数；

Decorator:维持一个指向Component对象的指针，该指针指向须要被装饰的对象；并定义一个与Component接口一致的接口；

ConcreteDecorator:向组件添加职责。

 

代码实现：

#include <iostream>
using namespace std;
class Component
{
public:
     virtual void Operation() = 0;
};
class ConcreteComponent : public Component
{
public:
    ConcreteComponent()
    {
        cout <<" ConcreteComponent "<< endl;
    }
     void Operation()
     {
          cout<<"I am no decoratored ConcreteComponent"<<endl;
     }
};
class Decorator : public Component
{
public:
     Decorator(Component *pComponent) : m_pComponentObj(pComponent) 
     {
         cout << " Decorator "<<endl;
     }
     void Operation()
     {
          if (m_pComponentObj != NULL)
          {
               m_pComponentObj->Operation();
          }
     }
protected:
     Component *m_pComponentObj;
};
class ConcreteDecoratorA : public Decorator
{
public:
     ConcreteDecoratorA(Component *pDecorator) : Decorator(pDecorator)
     {
         cout << " ConcreteDecoratorA "<<endl;
     }
     void Operation()
     {
          AddedBehavior();
          Decorator::Operation();
     }
     void  AddedBehavior()
     {
          cout<<"This is added behavior A."<<endl;
     }
};
class ConcreteDecoratorB : public Decorator
{
public:
     ConcreteDecoratorB(Component *pDecorator) : Decorator(pDecorator)
     {
         cout << " ConcreteDecoratorB "<<endl;
     }
     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;
}

 使用场合

1. 在不影响其余对象的状况下，以动态的，透明的方式给单个对象添加职责；
2. 处理那些能够撤销的职责；
3. 当不能采用生成子类的方法进行扩充时。一种状况是，可能存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增加。另外一种状况多是由于类定义被隐藏，或类定义不能用于生成子类。

注意事项

1. 接口的一致性；装饰对象的接口必须与它所装饰的Component的接口是一致的，所以，全部的ConcreteDecorator类必须有一个公共的父类；这样对于用户来讲，就是统一的接口；
2. 省略抽象的Decorator类；当仅须要添加一个职责时，没有必要定义抽象Decorator类。由于咱们经常要处理，现存的类层次结构而不是设计一个新系统，这时能够把Decorator向Component转发请求的职责合并到ConcreteDecorator中；
3. 保持Component类的简单性；为了保证接口的一致性，组件和装饰必需要有一个公共的Component类，因此保持这个Component类的简单性是很是重要的，因此，这个Component类应该集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中，不然Component类会变得过于复杂和臃肿，于是难以大量使用。赋予Component类太多的功能，也使得具体的子类有一些它们它们不须要的功能大大增大；

实现要点

1. Component类在Decorator模式中充当抽象接口的角色，不该该去实现具体的行为。并且Decorator类对于Component类应该透明，换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能；
2. Decorator类在接口上表现为“is-a”Component的继承关系，即Decorator类继承了Component类所具备的接口。但在实现上又表现为“has-a”Component的组合关系，即Decorator类又使用了另一个Component类。咱们可使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象；
3. Decortor模式并不是解决“多子类衍生的多继承”问题，Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义；
4. 对于Decorator模式在实际中的运用能够很灵活。若是只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类能够是ConcreteComponent的一个子类。若是只有一个ConcreteDecorator类，那么就没有必要创建一个单独的Decorator类，而能够把Decorator和ConcreteDecorator的责任合并成一个类。
5. Decorator模式的优势是提供了比继承更加灵活的扩展，经过使用不一样的具体装饰类以及这些装饰类的排列组合，能够创造出不少不一样行为的组合；
6. 因为使用装饰模式，能够比使用继承关系须要较少数目的类。使用较少的类，固然使设计比较易于进行。可是，在另外一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

与桥接模式的区别　

　　C++设计模式——桥接模式与装饰模式都是为了防止过分的继承，从而形成子类泛滥的状况。那么两者之间的主要区别是什么呢？桥接模式的定义是将抽象化与实现化分离（用组合的方式而不是继承的方式），使得二者能够独立变化。能够减小派生类的增加。若是光从这一点来看的话，和装饰者差很少，但二者仍是有一些比较重要的区别：

1. 桥接模式中所说的分离，实际上是指将结构与实现分离（当结构和实现有可能发生变化时）或属性与基于属性的行为进行分离；而装饰者只是对基于属性的行为进行封闭成独立的类，从而达到对其进行装饰，也就是扩展。好比：异常类和异常处理类之间就可使用桥接模式来实现完成，而不能使用装饰模式来进行设计；若是对于异常的处理须要进行扩展时，咱们又能够对异常处理类添加Decorator，从而添加处理的装饰，达到异常处理的扩展，这就是一个桥接模式与装饰模式的搭配；
2. 桥接中的行为是横向的行为，行为彼此之间无关联，注意这里的行为之间是没有关联的，就好比异常和异常处理之间是没有行为关联的同样；而装饰者模式中的行为具备可叠加性，其表现出来的结果是一个总体，一个各个行为组合后的一个结果。

 

转自：C++设计模式——装饰模式