动机

有时候需要给某个对象而不是整个类添加一些功能，使用继承也可以，但是子类行为是静态的而用户不能动态的控制；如果希望在无需修改代码且运行时为对象新增额外的行为，可以使用装饰器模式

使用场景

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

参与者

• Component：定义一个对象接口，可以给这些对象动态地添加职责
• ConcreteComponent：定义一个对象，可以给这个对象添加一些职责
• Decorator：维持一个指向Component对象的指针，并定义一个与Component接口一致的接口
• ConcreteDecorator：向组件添加职责

协作

• Decorator将请求转发给Component对象，并有可能在转发请求前后执行一些附加的动作

效果

• 优点：
  • 比静态继承更加灵活，无需创建新子类即可扩展对象行为，在运行时添加或删除对象的功能
  • 可以用多个装饰器来组合几种行为
  • 单一职责原则
  • 避免在层级结构高层的类有太多的特征。Decorator模式提供了一种“即用即付”的方法来添加职责，他并不试图再一个复杂的可定制的类中添加功能，可以从简单的部件组合出复杂的功能
• 缺点：
  • Decorator与它的Component不一样。Decorator是一个透明的包装，使用装饰时不应该依赖对象标识
  • 使用Decorator模式进行系统设计会产生很多小对象，这些小对象仅在相互连接的方式上有所不同，而不是他们的类或他们的属性值有所不同
  • 当Component类原本就很庞大时使用Decorator模式代价太高，Stratety模式相对更好一些

实现

• 接口的一致性：装饰对象的接口必须要与它所修饰的Component的接口一致，因此所有的具体Decorator类必须有一个公共父类
• 省略抽象的Decorator类：当仅需要添加一个职责时没必要定义抽象的Decorator类
• 保持Component类的简单性：为了保证接口的一致性，组件和装饰必须有一个公共的Component父类，因此保持这个类的简单性很重要，它应集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中，否则Component类会变得过于复杂和庞大；功能也不能太多，否则会导致子类有一些它们并不需要的功能；
• 改变对象外壳与改变对象内核：可以将Decorator看作一个对象的外壳，它可以改变这个对象的行为。另一种方法是改变对象的内核，如Strategy模式；区分这两种模式的场合：当Component类很庞大时使用Decorator模式代价太高，Strategy模式相对更好一点
• 具体的实现方式（结合类图看）
  • 确保业务逻辑可用一个基本组件及多个额外可选层次表示。
  • 找出可选组件和可选层次的通用方法（什么是通用方法），创建一个组件接口并在其中声明这些方法
  • 创建一个具体组件类，并定义其基础行为
  • 创建装饰基类，使用一个成员变量存储指向被封装对象的引用。该成员变量必须被声明为组件接口类型，从而能在运行时连接具体组件和装饰。 装饰基类必须将所有工作委派给被封装的对象。
  • 确保所有类实现组件接口。
  • 将装饰基类扩展为具体装饰。 具体装饰必须在调用父类方法（总是委派给被封装对象）之前或之后执行自身的行为。
  • 客户端代码负责创建装饰并将其组合成客户端所需的形式。

相关模式

• Adapter模式：装饰器改变对象的职责而不改变它的接口；而适配器给对象一个全新的接口
• Composite模式
• Stratety模式：两种改变对象的途径：装饰改变对象的外表，策略模式改变对象的内核
  • Decorator模式中装饰对组件是透明的
  • Strategy中component组件本身知道可能进行哪些扩充，因此必须引用并维护相应的策略

应用和思考

• 由于Decorator模式仅从外部改变组件，因此组件无需对它的装饰有任何了解，也就是说这些装饰对该组件是透明的
• 将业务逻辑组织为层次结构，可以为各层创建一个装饰，在运行时将各种不同的逻辑组合成对象

类图