设计模式-装饰模式（Decorator）
记忆关键字：附加职责
定义：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
分析：装饰器模式是一种结构型模式，它的主要意义是对原有的类进行功能扩展。依靠组合来实现类功能的扩展，并且支持多种嵌套。
UML类图：
1. 涉及的角色
1）Component接口
Strategy角色负责决定实现策略所必需的接口（API）。在示例程序中，由strategy接口扮演此角色。
2）ConcreteComponent类
ConcreteComponent类是被包装的实现类
3）Decorator抽象类
所有的包装类，都继承自Decorator抽象类，而Decorator类又实现了Component接口，这么做是为了实现多层嵌套包装。
4）ConcreteDecorator类
具体的包装类，用于扩充被包装类的功能
2. 使用场景
动态地给对象添加功能,避免通过子类扩展功能。
3. 总结
### 3.1 优点
- 灵活性和可扩展性： 装饰器模式允许动态地、透明地向对象添加新的职责，而无需修改其代码。这提供了更大的灵活性和可扩展性，使得系统更容易维护和升级。
- 避免类爆炸： 装饰器模式通过组合而不是继承的方式来实现功能的添加，避免了类爆炸问题。通过组合，可以创建各种不同的组合，而不需要为每个具体组合创建一个新的类。
- 符合开闭原则： 装饰器模式支持对现有代码的修改关闭，对扩展开放。可以在不修改现有代码的情况下引入新的装饰器类，从而增加新的功能。
- 易于理解和使用： 装饰器模式不需要深入理解系统的内部工作原理，因此较易于理解和使用。它提供了一种直观的方式来为对象添加功能。
### 3.2 缺点
- 复杂性增加： 使用装饰器模式会引入许多小对象，可能导致代码复杂性增加。尤其是当有多个装饰器叠加使用时，代码可读性和维护性可能降低。
- 顺序敏感： 装饰器的顺序很重要。如果装饰器的添加顺序不正确，可能会导致意外的结果。这增加了使用装饰器模式的复杂性。
- 不适用于所有情况： 装饰器模式并不总是适用于所有的场景。在一些情况下，可能存在更简单、更直接的解决方案。
虽然存在一些缺点，但装饰器模式在很多场景下都是一种有用的设计模式，特别是需要灵活性和可扩展性的情况。在实际应用中，根据具体需求和场景来选择使用装饰器模式或其他设计模式。
4. 注意
装饰模式的装饰顺序很重要，最理想的情况是保证装饰类之间彼此独立，这样它们就可以以任意的顺序进行组合了。