C++设计模式之装饰模式(2)

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

注意事项

1.接口的一致性；装饰对象的接口必须与它所装饰的Component的接口是一致的，因此，所有的ConcreteDecorator类必须有一个公共的父类；这样对于用户来说，就是统一的接口；

2.省略抽象的Decorator类；当仅需要添加一个职责时，没有必要定义抽象Decorator类。因为我们常常要处理，现存的类层次结构而不是设计一个新系统，这时可以把Decorator向Component转发请求的职责合并到ConcreteDecorator中；

3.保持Component类的简单性；为了保证接口的一致性，组件和装饰必须要有一个公共的Component类，所以保持这个Component类的简单性是非常重要的，所以，这个Component类应该集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中，否则Component类会变得过于复杂和臃肿，因而难以大量使用。赋予Component类太多的功能，也使得具体的子类有一些它们它们不需要的功能大大增大；

实现要点

1.Component类在Decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且Decorator类对于Component类应该透明，换言之Component类无需知道Decorator类，Decorator类是从外部来扩展Component类的功能；

2.Decorator类在接口上表现为“is-a”Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为“has-a”Component的组合关系，即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象，且装饰后的对象仍然是一个Component对象；

3.Decortor模式并非解决“多子类衍生的多继承”问题，Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义；

4.对于Decorator模式在实际中的运用可以很灵活。如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Decorator和ConcreteDecorator的责任合并成一个类。

5.Decorator模式的优点是提供了比继承更加灵活的扩展，通过使用不同的具体装饰类以及这些装饰类的排列组合，可以创造出很多不同行为的组合；