理解设计模式：使用 Long Night (GOT) 示例的装饰器！

经典的设计模式有23种，详见原著《设计模式：可复用面向对象软件的元素》。这些模式为软件开发中经常遇到的特定问题提供了解决方案。

在本文中，我将描述装饰器模式是什么；以及如何以及何时应用它。

装饰器模式：基本思想

在面向对象编程中，装饰器模式是一种设计模式，它允许动态地将行为添加到单个对象，而不会影响同一类中其他对象的行为。——维基百科

动态地为对象附加额外的职责。装饰器提供了一种灵活的替代子类化方法来扩展功能——设计模式：可复用面向对象软件的元素

此模式的主要特点是它允许你动态地（在运行时）为对象附加额外的职责。因此，此模式解决了两个问题：

当您需要能够在运行时为对象分配额外的行为而不破坏使用这些对象的代码时。
当无法使用继承来扩展类时。

总而言之，装饰器模式允许在运行时使用聚合而不是继承为对象添加新行为。该模式的 UML 图如下：

类是一个接口，它定义了每个组件或系列Component中必须实现的不同操作。类使用组合而非继承来改进组件。因此，类包装了，定义了每个组件的通用接口，并将公共操作委托给。最后，被实现用于在运行时向对象添加、修改或删除行为。ConcreteComponentDecorator
DecoratorDecoratorComponentDecoratorComponentConcreteDecorator

您需要动态、透明地向各个对象添加职责，也就是说，不影响其他对象。
您需要添加可以随时撤销的职责。
当使用继承的行为非常复杂时，因为必须创建大量的类。

装饰器模式有几个优点，总结如下：

由于装饰器使用单一职责，因此代码更易于使用、理解和测试，因为您可以将行为分成几个较小的类（装饰器）。
由于使用了聚合，因此对象的行为得到了扩展，而无需创建新的子类。
可以在运行时添加或删除对象的职责。
可以通过将对象包装到多个装饰器中来组合职责。

现在我将向您展示如何使用 JavaScript/TypeScript 实现此模式。在应用此模式之前，务必先了解您要解决的问题。如果您查看下面的 UML 图，它展示了三个组件（ComponentA、ComponentB 和 ComponentC）的经典继承关系，这些组件继承自一个实现了 Component 接口的组件（ComponentBase）。每个组件都实现了特定的行为和属性，并且彼此不同（遵循里氏替换原则）。

软件不断发展，我们需要具有不同组件的属性和行为的对象。

因此，我们得到以下 UML 图。

出现的第一个问题是类的数量激增。每个组件之间都有一个类来关联。如果出现一个新的组件（ComponentD），由于我们问题的架构基于继承，类的数量会继续激增。最后，针对类数量激增问题，我们可以进行一个小的改进，即重新组织类的继承关系，使所有类都继承自同一个类，如与我们正在解决的问题相关的最后一张图所示。

相关的Component和ComponentBase代码如下：

最后，与每个类相关的代码如下：

解决方案是使用装饰器模式。使用此模式的新 UML 图如下所示：

因此，解决方案是使用聚合而不是继承。在此模式中，组件接口被维护，该接口定义了装饰器和具体组件必须执行的操作。需要注意的是，ConcreteComponent 和 Decorator 类都实现了组件接口。此外，Decorator 类还通过依赖注入的方式拥有一个组件实例。从注释中可以看出，责任委托是通过注入的对象来执行的，或者说是行为的补充。

最后，每个装饰器都实现一个具体的行为，这些行为可以根据需要进行组合。此时，我们应用了单一职责原则，因为每个装饰器只执行一项任务，并承担唯一的职责。

我们现在来看看通过实现此模式生成的代码：