设计模式之装饰者模式

装饰者模式 （Decorator）

定义

在不改变现有对象结构的情况下，动态地给对象添加一些职责。

说明

从命名上看装饰者模式和外观模式有些相像，其实二者完全不同，外观模式静态地对外提供接口，而装饰者是动态地给接口添加功能，一个是在编码阶段完成的，一个是在程序运行阶段动态执行的。
一般情况下要想扩展一个类的功能会通过继承的方式在子类中添加类的属性和行为，但是我们都清楚继承不是一个好的解决方案，设计模式也不提倡在代码中有太多继承，一个好的设计者应该像躲避瘟疫一样避免在程序设计中使用继承。
扩展对象功能的方式除了继承还有很多，装饰者模式以对客户端透明的方式扩展对象的职能，是继承关系的一种替代方案。
装饰者模式要对客户端透明，客户端不应该知道装饰者的存在，也就是说客户端并不能感受到对象被装饰前后有任何区别。装饰者装饰的目标是对象，它不应该改变对象原有的属性，而是对功能的扩展，与子类的作用相似，但又比子类灵活。装饰者模式可以在不创造更多子类的情况下，将对象的功能加以扩展。在程序设计中继承超过两层就要考虑是不是设计有问题，是否应该另寻道路。
在系统设计中无法预测到将来会有怎样的功能拓展，或者对象有很多种使用场景，每个场景职能不同，需要程序员自己选择功能搭配等，类似这种无法一次性确定需求的情况可以考虑使用装饰者模式。
装饰者模式的本质是将一个对象嵌入到另一个对象中，我们称这个嵌入的对象为装饰，装饰应该拥有被嵌入者所有的属性方法，以体现调用的透明性。装饰可以将用户的请求转发给被装饰者，并且在转发的前后可以做一些赋能。装饰可以实现嵌套，并且每一层嵌套都要保证被装饰者的功能在装饰前后不能发生改变，这也是透明性的体现。

装饰者模式类图：

结构

装饰者模式中的角色：

• Componet 抽象构建角色
  用来规范需要添加职责的对象
• ConcreteComponet 具体构建
  具体需要添加职能的对象
• Decorator 抽象装饰者
  内部持有需要装饰的具体对象，并且与需要装饰的具体对象实现了同样的接口规范
• ConcreteDecorator 具体装饰者
  真正向被装饰者添加职责的对象

注意! 装饰者与被装饰者必须要实现同一个接口，这是为了确保装饰后的对象在不改变其他调用类的前提下依然能够使用，这是实现调用透明性的保证。

装饰者模式的优势

1. 装饰类与被装饰类可以独立发展，而不会相互耦合。
2. 装饰者模式是继承关系的一种替代方案。
3. 装饰者模式可以动态地扩展一个类的功能。

装饰者模式的使用

装饰者模式在Java语言中的最著名的应用莫过于Java I/O标准库的设计了。

由于Java I/O库需要很多功能的组合，如果这些功能的实现方式都是用继承的方法，那么每一种组合都需要一个类，这样就会造成大量重复的类出现。而如果采用装饰者模式，在保证功能一定的情况下，类的数目就会大大减少，代码的复用率也会大大提高。因此装饰者模式是Java I/O库的基本模式。