动机

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

使用场景

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

参与者

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模式相对更好一点
具体的实现方式（结合类图看）
- 确保业务逻辑可用一个基本组件及多个额外可选层次表示。
- 找出可选组件和可选层次的通用方法（什么是通用方法），创建一个组件接口并在其中声明这些方法
- 创建一个具体组件类，并定义其基础行为
- 创建装饰基类，使用一个成员变量存储指向被封装对象的引用。该成员变量必须被声明为组件接口类型，从而能在运行时连接具体组件和装饰。装饰基类必须将所有工作委派给被封装的对象。
- 确保所有类实现组件接口。
- 将装饰基类扩展为具体装饰。具体装饰必须在调用父类方法（总是委派给被封装对象）之前或之后执行自身的行为。
- 客户端代码负责创建装饰并将其组合成客户端所需的形式。