装饰者模式

2020-12-20

意图：动态地给一个对象添加一些额外的职责。就增加功能来说。Decorator模式相比生成子类更为灵活。

动机：在某些情况下我们可能会“过度的使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。

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

结构如下:

参与者：

Component:定义一个对象接口，可以给这些对象动态地添加职责。

ConcreteComponent: 定义一个对象，可以给这个对象添加一些职责。

Decorator：维持一个指向Component对象的指针，并定义一个与Component接口一致的接口。

Decorator将请求转发给它的Component对象，并由可能在转发请求前后执行一些附加操作。

优点和缺点：

比静态继承更加灵活，可以更加灵活的给对象添加职责。

避免在层次结构中高层的类有太多的特征。

Decorator与它的Component不一样，采用Decorator模式往往会产生许多类似的小对象。

实现:

其实现主要注意一下几点：（1）接口的一致性（2）省略抽象的Decorator类（3）保持Component类的简单性（4）改变对象的外壳和改变对象的内核（Strategy模式）。

代码示例如下：

#include <iostream>
class Component{
public:
  Component(){}
  virtual ~Component(){}
  virtual void Operation(){}
};

class ConcreteComponent : public Component{
public:
  void Operation() override {
    std::cout << "I am concrete operation" << std::endl;
  }
};

class Decorator : public Component{
public:
  virtual void Operation(){
    _component->Operation();
  }

protected:
  Component* _component;
};

class ConcreteDecoratorA : public Decorator{
public:
  ConcreteDecoratorA(Component* com){
    _component = com;
  }
  void Operation(){
      AddBehavior();
    Decorator::Operation();
  }

private:
  void AddBehavior(){
    std::cout << " I am a decorator" << std::endl;
  }
};

int main(int argc,char * argv[]){
  Component *component = new ConcreteComponent;
  Component* A = new ConcreteDecoratorA(component);
  A->Operation();
  delete component;
  delete A;
  return 0;
}