动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更
为灵活。
有时我们希望给某个对象而不是整个类添加一些功能。例如,一个图形用户界面工具箱允许
你对任意一个用户界面组件添加一些特性,例如边框,或是一些行为,例如窗口滚动。
使用继承机制是添加功能的一种有效途径,从其它类继承过来的边框特性可以被多个子类的
实例使用。但这种方法不够灵活。因为边框的选择是静态的,用户不能控制对组件加边框的
方式和时机。
一种极为灵活的方式是将组件嵌入另一个个对象中,由这个对象添加边框。我们称这个嵌入
的对象为装饰。这个装饰与它所装饰的组件的接口一致,因此它对使用该组件的客户透明。
它将客户请求转发给该组件,并且可能在转发前后执行一些额外的动作(例如画一个边框)。
透明性使得你可以递归的嵌套多个装饰,从而可以添加任意多的功能。
适用性:
1、在不影响其它对象的情况下,以动态、透明的方式给单个对象添加职责。
2、处理那些可以撤消的职责。
3、当不能采用生成子类的方法进行扩充时。一种情况是,可能有大量独立的扩展,为支持
每一种组合将产生大量的子类,使得子类数目呈爆炸性增长。另一种情况可能是因为类定义
被隐藏,或类定义不能用于生成子类。
使用Decorator模式应注意以下几点:
1、接口的一致性:装饰对象的接口必须与它所装饰的Component的接口是一致的。因此,所有
的ConcreteDecorator类必须有一个公共的父类(至少在C++中如此)
2、省略抽象的Decorator类:当你仅需要添加一个职责时,没有必要定义抽象Decorator类,你常
常需要处理现存的类层次结构而不是设计一个新系统,这时你可以把Decorator的Component转发
请求的职责合并到ConcreteDecorator中。
3、保持Component类的简单性: 为了保证接口的一致性,组件和装饰必须有一个公共的Component
父类。因此保持这个类的简单性是很重要的,即,它应集中于定义接口而不是存储数据。对数据表示
的定义应延迟到子类中,否则Component类会变得过于复杂和庞大,因而难以大量使用。赋予Component
太多的功能也使得,具体的子类有一些它们并不需要的功能的可能性大大增加。
4、改变对象外壳与改变对象内核。 我们可以将Decorator看作一个对象的外壳。它可以改变这个对象
的行为。另外一种方法是改变对象的内核。例如,Strategy模式就是一个用于改变内核的很好的模式。
当Component类原本就很庞大时,使用Decorator模式的代价太高,Strategy模式相对更好一些。
由于Decorator模式仅从外部改变组件,因此组件无需对它的装饰有任何了解;也就是说,这些装饰对该
组件是透明的。
相对而言这个模式比较简单,以下为书中相关代码,略作修改。


















































































































