装饰者模式：动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
装饰者模式类图
装饰者模式的关键点
装饰者与被装饰者必须是一样的类型，即他们有同样的超类型。
ConcreteComponentA想要装饰ConcreteComponentB及其子类，ConcreteComponentA中必须有一个ConcreteComponentB的引用，而ConcreteComponentB及其子类都是Component的实现类，因此，ConcreteComponentA中只需要引用Component即可。如果仅从这个程度上来说，完全是策略模式的模型，见下图：
但仅仅通过上图的类结构（也就是策略模式）我们无法完成装饰的目的。因为ConcreteComponentA必须拥有和ConcreteComponentB一样的行为，才能在调用ConcreteComponentB的doSometing()方法时，增加一些额外的职业或者提供更强大的功能，或者完全覆盖掉ConcreteComponentB的doSometing()的行为。因此我们的ConcreteComponentA也必须实现Component接口。也就是说ConcreteComponentA除了拥有一个Component的引用之外，自己还要实现Component接口。ConcreteComponentA除了拥有Component的引用外，ConcreteComponentA也可以再次被Component的其他实现类装饰，也就是说他有可能成为ConcreteComponentC中Component引用的实现，因此ConcreteComponentA实现Component接口也是必须的。
装饰者该做的事情就是增加行为（或者修改或者覆盖——这些通过该模式可以实现，但不是装饰者模式的意图）到被包装对象上。不要企图窥视装饰者链中的每一个装饰者，虽然可以实现。
你可以用无数个装饰者包装一个组件。装饰者对Client来说是透明的，除非Client依赖于Component的具体类型，但这样做就无法适应变化了。装饰者模式可以动态的装饰任何对象，因为他们通过组合Component来完成装饰的，而不是通过继承。装饰者模式会导致设计中出现许多小对象，如果过度使用，会让程序变得复杂。
参考资料：
Head First 设计模式 (中国电力出版社)