装饰（Decorator）模式又名包装（Wrapper）模式[GOF95]。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。
装饰模式使用原来被装饰的类的一个子类的实例，把客户端的调用委派到被装饰类。装饰模式的关键在于这种模式是完全透明的。
抽象构建角色（Component）：给出一个抽象接口，以规范准备接收附加责任的对象。
具体构建角色（Concrete Component）：定义一个将要接收附加责任的类。
装饰角色（Decorator）：持有一个构建（Component）对象的实例。并第一个与抽象构建接口一样的接口。
具体装饰角色（Concrete Decorator）：负责给构建对象贴上附加的责任。
在以下情况下应当使用装饰模式：
1. 需要扩展一个类的功能，或给一个类增加附加责任。
2. 需要动态地给一个对象增加功能，这些功能可以再动态地撤销
3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。
使用装饰模式主要有以下的优点：
1. 装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。
3. 这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错。
使用装饰模式主要有以下的缺点：
由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。
使用时要注意以下几点：
1.一个装饰类的接口必须与被装饰类的接口相容。
2.尽量保持（ Component）做为一个“轻”类，不要把太多的逻辑和状态放在 Component里面。
3.如果只有一个 ConcreteComponent 类而没有抽象的 Component 类（接口），那么Decorator 类经常可以是 ConcreteComponent 的一个子类。如下图所示：
4.如果只有一个 ConcreteDecorator 类，那么就没有必要建立一个单独的 Decorator 类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。
总结：这个装饰者模式 从结构上来说 就是有一个基类定义了一些简单的方法，然而 在实现的子类当中有一个子类 不但继承了这个基类而且还聚合了基类，等到具体的装饰对象的时候就可以直接继承与这个装饰对象，去实现自己。 客户端在调用的时候 就可以直接调用 这个被装饰的子类，并且还可以实现多层次的 附加操作，也就是多层包装，至于包装的顺序以及内容可以自己通过继承装饰类 进行扩展。