您现在的位置是：首页 >其他 >《设计模式》之装饰器模式网站首页其他

1、定义

动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。

2、动机

1. 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
2. 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响降到最低？

3、类结构

CComponent类：装饰器模式中公共方法的类，位于装饰器模式最顶层。
CConcrateComponent类：具体的被装饰的类。
Decorator类：装饰器模式基类，所有具体装饰器类的父类，实现部分装饰职能，其继承与CComponent类，且其中包含一个CComponent类型的成员变量(动态的增加功能所需要)。
ConcrateDecoratorA和ConcrateDecoratorB类：两个具体的装饰器类，实现具体的装饰功能。装饰功能的实现是通过调用被装饰对象的方法，和装饰器自身的方法。
注：如果具体装饰器类和装饰器基类中的接口保存一致，那么被称为透明装饰器(理想情况下的状态)，否则被称为非透明装饰器

4、优缺点

优点：
装饰器比继承具有更大的灵活性，可以动态的决定是增加或减掉一个装饰。通过使用不同的具体装饰类和这些类的排列组合，可以创建出很多不同行为的组合。
使用继承进行的扩展是静态的，在编译器就已经决定；但是装饰器模式，可以由用户动态决定扩展功能的加入方式和时机。
缺点：
装饰器比继承使用的类数量减少了，但是比继承关系使用更多的对象，更多的对象会增加排错的复杂度。

5、注意事项

1. 装饰器类的接口必须与被装饰的类的接口相容
2. Component类的职责在于为各个具体的装饰器类提供共同的接口，而不是数据存储，不要把太多的逻辑和状态放在Component类中。

6、总结

1. 通过采用组合而非继承的手法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
2. Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
3. Decorator模式的目的并非解决“多子类衍生的多继承”问题，Decorator模式应用的要点在于解决“主体类在多个方向上的扩展功能”—是为“装饰”的含义。

7、代码实现(C++)

装饰器模式源代码实现