Decorator 装饰模式

一.意图

装饰模式是一种结构型设计模式， 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。

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

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码& 减少子类个数）。------《设计模式》GoF

二.问题

假设你正在开发一个提供通知功能的库， 其他程序可使用它向用户发送关于重要事件的通知。

库的最初版本基于 通知器Notifier类， 其中只有很少的几个成员变量， 一个构造函数和一个 send发送方法。 该方法可以接收来自客户端的消息参数， 并将该消息发送给一系列的邮箱， 邮箱列表则是通过构造函数传递给通知器的。 作为客户端的第三方程序仅会创建和配置通知器对象一次， 然后在有重要事件发生时对其进行调用。

此后某个时刻， 你会发现库的用户希望使用除邮件通知之外的功能。 许多用户会希望接收关于紧急事件的手机短信， 还有些用户希望在微信上接收消息， 而公司用户则希望在 QQ 上接收消息。

这有什么难的呢？ 首先扩展 通知器类， 然后在新的子类中加入额外的通知方法。 现在客户端要对所需通知形式的对应类进行初始化， 然后使用该类发送后续所有的通知消息。

但是很快有人会问： "为什么不同时使用多种通知形式呢？ 如果房子着火了， 你大概会想在所有渠道中都收到相同的消息吧。"

你可以尝试创建一个特殊子类来将多种通知方法组合在一起以解决该问题。 但这种方式会使得代码量迅速膨胀， 不仅仅是程序库代码， 客户端代码也会如此。

你必须找到其他方法来规划通知类的结构， 否则它们的数量会在不经意之间打破吉尼斯纪录。

三.解决方案

当你需要更改一个对象的行为时， 第一个跳入脑海的想法就是扩展它所属的类。 但是， 你不能忽视继承可能引发的几个严重问题。

• 继承是静态的。 你无法在运行时更改已有对象的行为， 只能使用由不同子类创建的对象来替代当前的整个对象。

• 子类只能有一个父类。 大部分编程语言不允许一个类同时继承多个类的行为。

其中一种方法是用聚合 或组合 ， 而不是继承 。 两者的工作方式几乎一模一样： 一个对象包含 指向另一个对象的引用， 并将部分工作委派给引用对象； 继承中的对象则继承了父类的行为， 它们自己能够完成这些工作。

你可以使用这个新方法来轻松替换各种连接的 "小帮手" 对象， 从而能在运行时改变容器的行为。 一个对象可以使用多个类的行为， 包含多个指向其他对象的引用， 并将各种工作委派给引用对象。 聚合 （或组合） 组合是许多设计模式背后的关键原则 （包括装饰在内）。 记住这一点后， 让我们继续关于模式的讨论。

封装器是装饰模式的别称， 这个称谓明确地表达了该模式的主要思想。 "封装器" 是一个能与其他 "目标" 对象连接的对象。 封装器包含与目标对象相同的一系列方法， 它会将所有接收到的请求委派给目标对象。 但是， 封装器可以在将请求委派给目标前后对其进行处理， 所以可能会改变最终结果。

那么什么时候一个简单的封装器可以被称为是真正的装饰呢？ 正如之前提到的， 封装器实现了与其封装对象相同的接口。 因此从客户端的角度来看， 这些对象是完全一样的。 封装器中的引用成员变量可以是遵循相同接口的任意对象。 这使得你可以将一个对象放入多个封装器中， 并在对象中添加所有这些封装器的组合行为。

比如在消息通知示例中， 我们可以将简单邮件通知行为放在基类 通知器中， 但将所有其他通知方法放入装饰中。

客户端代码必须将基础通知器放入一系列自己所需的装饰中。 因此最后的对象将形成一个栈结构。

实际与客户端进行交互的对象将是最后一个进入栈中的装饰对象。 由于所有的装饰都实现了与通知基类相同的接口， 客户端的其他代码并不在意自己到底是与 "纯粹" 的通知器对象， 还是与装饰后的通知器对象进行交互。

我们可以使用相同方法来完成其他行为 （例如设置消息格式或者创建接收人列表）。 只要所有装饰都遵循相同的接口， 客户端就可以使用任意自定义的装饰来装饰对象。

四.真实世界类比

穿衣服就是使用装饰师的例子。冷的时候，你会裹着毛衣。如果穿毛衣还是冷，可以穿外套。如果下雨了，你可以穿上雨衣。这些衣服都是"延伸"你的基本行为，但不是你身体的一部分，你可以随时脱掉任何不需要的衣服。

五.装饰模式结构

六.装饰模式适合应用场景

1. 当你需要在运行时为对象分配额外行为而不破坏使用这些对象的代码时，可以使用 Decorator 模式。

   Decorator 允许你将业务逻辑结构成多层，为每层创建一个装饰器，并在运行时用各种逻辑组合组合对象。客户端代码可以以相同方式处理所有这些对象，因为它们都遵循一个共同的接口。

2. 当通过继承来扩展对象行为变得尴尬或无法时，可以使用该模式。

   许多编程语言都有该关键词，可以用来防止类的进一步扩展。对于最后一个类，唯一能复用现有行为的方法是用你自己的封装器，使用Decorator模式将该类包裹起来。final

七.实现方式

1. 确保你的业务域可以作为主要组件表示，并且在上面覆盖多个可选层。

2. 弄清楚主成分和可选层共有的方法。创建一个组件接口，并在那里声明这些方法。

3. 创建一个具体的组件类，并定义其基础行为。

4. 创建一个基础装饰类。它应该有一个字段用于存储对包裹对象的引用。字段应声明组件接口类型，以便链接混凝土组件和装饰器。底座装饰师必须将所有工作委托给包裹的物品。

5. 确保所有类都实现了组件接口。

6. 通过从基础装饰器延伸来制作混凝土装饰器。具体装饰器必须在调用父方法之前或之后执行其行为（父方法总是委派给被包裹的对象）。

7. 客户代码必须负责创建装饰人员，并按照客户的需求进行配置。

八.装饰模式优缺点

1. 优点：

   • 你可以在不创建新子类的情况下扩展对象的行为。

   • 你可以在运行时添加或移除对象的责任。

   • 你可以通过将一个物体包裹到多个装饰器中来组合多种行为。

   • 单一责任原则。你可以将实现多种行为变体的单一类划分为几个较小的类。

2. 缺点

   • 很难从包装纸堆栈中移除特定的包装。

   • 很难实现装饰器，让它的行为不受装饰器堆栈的顺序影响。

   • 图层的初始配置代码可能看起来相当难看。

九.与其他模式的关系

• 适配器提供了完全不同的接口来访问现有对象。而装饰者模式的界面要么保持不变，要么被扩展。此外，Decorator支持递归合成，而使用适配器时无法实现。

• 通过适配器，你可以通过不同的接口访问已有的对象。而Proxy的界面保持不变。使用Decorator时，你可以通过增强的界面访问该物品。

• 责任链和装饰者的职业结构非常相似。这两种模式都依赖递归合成，通过一系列对象传递执行。然而，两者之间存在几个关键区

  CoR 处理程序可以独立执行任意作。他们也可以随时停止继续传递请求。另一方面，各种装饰器可以在保持与基础界面一致的前提下扩展对象的行为。此外，装饰师不得打断请求的流程。

• Composite 和 Decorator 的结构图相似，因为两者都依赖递归组合来组织开放数量的对象。

  Decorator 类似于 Composite，但只有一个子组件。还有一个显著区别：Decorator会给包裹物品增加额外责任，而Composite只是"总结"其子对象的结果。

  不过，这些模式也可以合作：你可以用 Decorator 扩展复合树中特定对象的行为。

• 大量使用复合材料和装饰器的设计通常可以从Prototype中受益。应用图案可以让你克隆复杂结构，而不是从零重建。

• 装饰者可以让你改变物体的皮肤，而策略则可以改变内脏。

• 装饰者和代理者结构相似，但意图却大相径庭。这两种模式都建立在构图原则之上，即一个对象应将部分工作委托给另一个。区别在于代理通常独立管理其服务对象的生命周期，而装饰器的组成始终由客户端控制。

十.示例代码

/**
 * The base Component interface defines operations that can be altered by
 * decorators.
 */
class Component {
 public:
  virtual ~Component() {}
  virtual std::string Operation() const = 0;
};
/**
 * Concrete Components provide default implementations of the operations. There
 * might be several variations of these classes.
 */
class ConcreteComponent : public Component {
 public:
  std::string Operation() const override {
    return "ConcreteComponent";
  }
};
/**
 * The base Decorator class follows the same interface as the other components.
 * The primary purpose of this class is to define the wrapping interface for all
 * concrete decorators. The default implementation of the wrapping code might
 * include a field for storing a wrapped component and the means to initialize
 * it.
 */
class Decorator : public Component {
  /**
   * @var Component
   */
 protected:
  Component* component_;
​
 public:
  Decorator(Component* component) : component_(component) {
  }
  /**
   * The Decorator delegates all work to the wrapped component.
   */
  std::string Operation() const override {
    return this->component_->Operation();
  }
};
/**
 * Concrete Decorators call the wrapped object and alter its result in some way.
 */
class ConcreteDecoratorA : public Decorator {
  /**
   * Decorators may call parent implementation of the operation, instead of
   * calling the wrapped object directly. This approach simplifies extension of
   * decorator classes.
   */
 public:
  ConcreteDecoratorA(Component* component) : Decorator(component) {
  }
  std::string Operation() const override {
    return "ConcreteDecoratorA(" + Decorator::Operation() + ")";
  }
};
/**
 * Decorators can execute their behavior either before or after the call to a
 * wrapped object.
 */
class ConcreteDecoratorB : public Decorator {
 public:
  ConcreteDecoratorB(Component* component) : Decorator(component) {
  }
​
  std::string Operation() const override {
    return "ConcreteDecoratorB(" + Decorator::Operation() + ")";
  }
};
/**
 * The client code works with all objects using the Component interface. This
 * way it can stay independent of the concrete classes of components it works
 * with.
 */
void ClientCode(Component* component) {
  // ...
  std::cout << "RESULT: " << component->Operation();
  // ...
}
​
int main() {
  /**
   * This way the client code can support both simple components...
   */
  Component* simple = new ConcreteComponent;
  std::cout << "Client: I've got a simple component:\n";
  ClientCode(simple);
  std::cout << "\n\n";
  /**
   * ...as well as decorated ones.
   *
   * Note how decorators can wrap not only simple components but the other
   * decorators as well.
   */
  Component* decorator1 = new ConcreteDecoratorA(simple);
  Component* decorator2 = new ConcreteDecoratorB(decorator1);
  std::cout << "Client: Now I've got a decorated component:\n";
  ClientCode(decorator2);
  std::cout << "\n";
​
  delete simple;
  delete decorator1;
  delete decorator2;
​
  return 0;
}

执行结果

Client: I've got a simple component:
RESULT: ConcreteComponent
​
Client: Now I've got a decorated component:
RESULT: ConcreteDecoratorB(ConcreteDecoratorA(ConcreteComponent))