--- title: 设计模式之装饰模式 date: 2015-01-15 15:41:00 order: 10 categories: - 设计 - 设计模式 tags: - 设计 - 设计模式 permalink: /pages/c6884edf/ --- # 设计模式之装饰模式 ## 意图 **装饰模式** (Decorator) 是一种结构型设计模式，**动态**地给一个对象**添加**一些**额外的职责**。就增加功能来说，Decorator 模式相比生成子类更为灵活。 - 装饰对象和真实对象有相同的接口。这样客户端对象就能以和真实对象相同的方式和装饰对象交互。 - 装饰对象包含一个真实对象的引用（reference）。 - 装饰对象接受所有来自客户端的请求。它把这些请求转发给真实的对象。 - 装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运行时，不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中，通常是通过继承来实现对给定类的功能扩展。 ## 适合场景 - 如果你希望在无需修改代码的情况下即可使用对象， 且希望在运行时为对象新增额外的行为， 可以使用装饰模式。 - 如果用继承来扩展对象行为的方案难以实现或者根本不可行， 你可以使用该模式。 ## 结构 ![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210430172133.png) ### 结构说明 1. **部件** （Component） 声明封装器和被封装对象的公用接口。 2. **具体部件** （Concrete Component） 类是被封装对象所属的类。 它定义了基础行为， 但装饰类可以改变这些行为。 3. **基础装饰** （Base Decorator） 类拥有一个指向被封装对象的引用成员变量。 该变量的类型应当被声明为通用部件接口， 这样它就可以引用具体的部件和装饰。 装饰基类会将所有操作委派给被封装的对象。 4. **具体装饰类** （Concrete Decorators） 定义了可动态添加到部件的额外行为。 具体装饰类会重写装饰基类的方法， 并在调用父类方法之前或之后进行额外的行为。 5. **客户端** （Client） 可以使用多层装饰来封装部件， 只要它能使用通用接口与所有对象互动即可。 ### 结构代码范式 **Component** : 定义一个对象接口，可以给这些对象动态地添加职责。 ```java interface Component { public void operation(); } ``` **ConcreteComponent** : 实现 **Component** 定义的接口。 ```java class ConcreteComponent implements Component { @Override public void operation() { System.out.println("初始行为"); } } ``` **Decorator** : 装饰抽象类，继承了 Component， 从外类来扩展 Component 类的功能，但对于 Component 来说，是无需知道 Decorator 的存在的。 ```java class Decorator implements Component { // 持有一个 Component 对象，和 Component 形成聚合关系 protected Component component; // 传入要进一步修饰的对象 public Decorator(Component component) { this.component = component; } @Override // 调用要修饰对象的原方法 public void operation() { component.operation(); } } ``` **ConcreteDecorator** : 具体的装饰对象，起到给 Component 添加职责的功能。 ```java class ConcreteDecoratorA extends Decorator { private String addedState = "新属性1"; public ConcreteDecoratorA(Component component) { super(component); } public void operation() { super.operation(); System.out.println("添加属性: " + addedState); } } class ConcreteDecoratorB extends Decorator { public ConcreteDecoratorB(Component component) { super(component); } public void operation() { super.operation(); AddedBehavior(); } public void AddedBehavior() { System.out.println("添加行为"); } } ``` 【客户端】 ```java public class DecoratorPattern { public static void main(String[] args) { Component component = new ConcreteComponent(); component.operation(); System.out.println("======================================"); Decorator decoratorA = new ConcreteDecoratorA(component); decoratorA.operation(); System.out.println("======================================"); Decorator decoratorB = new ConcreteDecoratorB(decoratorA); decoratorB.operation(); } } ``` 【输出】 ``` 初始行为 ====================================== 初始行为 添加属性: 新属性1 ====================================== 初始行为 添加属性: 新属性1 添加行为 ``` ## 伪代码 ![img](https://raw.githubusercontent.com/dunwu/images/master/snap/20210430172723.png) 在本例中， 装饰模式能够对敏感数据进行压缩和加密， 从而将数据从使用数据的代码中独立出来。 程序使用一对装饰来封装数据源对象。 这两个封装器都改变了从磁盘读写数据的方式： - 当数据即将被**写入磁盘**前， 装饰对数据进行加密和压缩。 在原始类对改变毫无察觉的情况下， 将加密后的受保护数据写入文件。 - 当数据刚**从磁盘读出**后， 同样通过装饰对数据进行解压和解密。 装饰和数据源类实现同一接口， 从而能在客户端代码中相互替换。 ```java // 装饰可以改变组件接口所定义的操作。 interface DataSource is method writeData(data) method readData():data // 具体组件提供操作的默认实现。这些类在程序中可能会有几个变体。 class FileDataSource implements DataSource is constructor FileDataSource(filename) { ... } method writeData(data) is // 将数据写入文件。 method readData():data is // 从文件读取数据。 // 装饰基类和其他组件遵循相同的接口。该类的主要任务是定义所有具体装饰的封 // 装接口。封装的默认实现代码中可能会包含一个保存被封装组件的成员变量，并 // 且负责对其进行初始化。 class DataSourceDecorator implements DataSource is protected field wrappee: DataSource constructor DataSourceDecorator(source: DataSource) is wrappee = source // 装饰基类会直接将所有工作分派给被封装组件。具体装饰中则可以新增一些 // 额外的行为。 method writeData(data) is wrappee.writeData(data) // 具体装饰可调用其父类的操作实现，而不是直接调用被封装对象。这种方式 // 可简化装饰类的扩展工作。 method readData():data is return wrappee.readData() // 具体装饰必须在被封装对象上调用方法，不过也可以自行在结果中添加一些内容。 // 装饰必须在调用封装对象之前或之后执行额外的行为。 class EncryptionDecorator extends DataSourceDecorator is method writeData(data) is // 1. 对传递数据进行加密。 // 2. 将加密后数据传递给被封装对象 writeData（写入数据）方法。 method readData():data is // 1. 通过被封装对象的 readData（读取数据）方法获取数据。 // 2. 如果数据被加密就尝试解密。 // 3. 返回结果。 // 你可以将对象封装在多层装饰中。 class CompressionDecorator extends DataSourceDecorator is method writeData(data) is // 1. 压缩传递数据。 // 2. 将压缩后数据传递给被封装对象 writeData（写入数据）方法。 method readData():data is // 1. 通过被封装对象的 readData（读取数据）方法获取数据。 // 2. 如果数据被压缩就尝试解压。 // 3. 返回结果。 // 选项 1：装饰组件的简单示例 class Application is method dumbUsageExample() is source = new FileDataSource("somefile.dat") source.writeData(salaryRecords) // 已将明码数据写入目标文件。 source = new CompressionDecorator(source) source.writeData(salaryRecords) // 已将压缩数据写入目标文件。 source = new EncryptionDecorator(source) // 源变量中现在包含： // Encryption > Compression > FileDataSource source.writeData(salaryRecords) // 已将压缩且加密的数据写入目标文件。 // 选项 2：客户端使用外部数据源。SalaryManager（工资管理器）对象并不关心 // 数据如何存储。它们会与提前配置好的数据源进行交互，数据源则是通过程序配 // 置器获取的。 class SalaryManager is field source: DataSource constructor SalaryManager(source: DataSource) { ... } method load() is return source.readData() method save() is source.writeData(salaryRecords) // ...其他有用的方法... // 程序可在运行时根据配置或环境组装不同的装饰堆桟。 class ApplicationConfigurator is method configurationExample() is source = new FileDataSource("salary.dat") if (enabledEncryption) source = new EncryptionDecorator(source) if (enabledCompression) source = new CompressionDecorator(source) logger = new SalaryManager(source) salary = logger.load() // ... ``` ## 案例 **使用示例：** 装饰模式在 Java 代码中可谓是标准配置， 尤其是在与流式加载相关的代码中。 Java 核心程序库中有一些关于装饰的示例： - [`java.io.InputStream`](http://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html)、 [`Output­Stream`](http://docs.oracle.com/javase/8/docs/api/java/io/OutputStream.html)、 [`Reader`](http://docs.oracle.com/javase/8/docs/api/java/io/Reader.html) 和 [`Writer`](http://docs.oracle.com/javase/8/docs/api/java/io/Writer.html) 的所有代码都有以自身类型的对象作为参数的构造函数。 - [`java.util.Collections`](http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html)； [`checked­XXX()`](http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#checkedCollection-java.util.Collection-java.lang.Class-)、 [`synchronized­XXX()`](http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#synchronizedCollection-java.util.Collection-) 和 [`unmodifiable­XXX()`](http://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#unmodifiableCollection-java.util.Collection-) 方法。 - [`javax.servlet.http.HttpServletRequestWrapper`](http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequestWrapper.html) 和 [`Http­Servlet­Response­Wrapper`](http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponseWrapper.html) **识别方法**： 装饰可通过以当前类或对象为参数的创建方法或构造函数来识别。 ## 与其他模式的关系 - [适配器模式](https://refactoringguru.cn/design-patterns/adapter)可以对已有对象的接口进行修改， [装饰模式](https://refactoringguru.cn/design-patterns/decorator)则能在不改变对象接口的前提下强化对象功能。 此外， *装饰*还支持递归组合， *适配器*则无法实现。 - [适配器](https://refactoringguru.cn/design-patterns/adapter)能为被封装对象提供不同的接口， [代理模式](https://refactoringguru.cn/design-patterns/proxy)能为对象提供相同的接口， [装饰](https://refactoringguru.cn/design-patterns/decorator)则能为对象提供加强的接口。 - [责任链模式](https://refactoringguru.cn/design-patterns/chain-of-responsibility)和[装饰模式](https://refactoringguru.cn/design-patterns/decorator)的类结构非常相似。 两者都依赖递归组合将需要执行的操作传递给一系列对象。 但是， 两者有几点重要的不同之处。 - [责任链](https://refactoringguru.cn/design-patterns/chain-of-responsibility)的管理者可以相互独立地执行一切操作， 还可以随时停止传递请求。 另一方面， 各种*装饰*可以在遵循基本接口的情况下扩展对象的行为。 此外， 装饰无法中断请求的传递。 - [组合模式](https://refactoringguru.cn/design-patterns/composite)和[装饰](https://refactoringguru.cn/design-patterns/decorator)的结构图很相似， 因为两者都依赖递归组合来组织无限数量的对象。 - *装饰*类似于*组合*， 但其只有一个子组件。 此外还有一个明显不同： *装饰*为被封装对象添加了额外的职责， *组合*仅对其子节点的结果进行了 “求和”。 - 但是， 模式也可以相互合作： 你可以使用*装饰*来扩展*组合*树中特定对象的行为。 - 大量使用[组合](https://refactoringguru.cn/design-patterns/composite)和[装饰](https://refactoringguru.cn/design-patterns/decorator)的设计通常可从对于[原型模式](https://refactoringguru.cn/design-patterns/prototype)的使用中获益。 你可以通过该模式来复制复杂结构， 而非从零开始重新构造。 - [装饰](https://refactoringguru.cn/design-patterns/decorator)可让你更改对象的外表， [策略模式](https://refactoringguru.cn/design-patterns/strategy)则让你能够改变其本质。 - [装饰](https://refactoringguru.cn/design-patterns/decorator)和[代理](https://refactoringguru.cn/design-patterns/proxy)有着相似的结构， 但是其意图却非常不同。 这两个模式的构建都基于组合原则， 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于*代理*通常自行管理其服务对象的生命周期， 而*装饰*的生成则总是由客户端进行控制。 ## 参考资料 - [《Head First 设计模式》](https://book.douban.com/subject/2243615/) - [《大话设计模式》](https://book.douban.com/subject/2334288/) - [设计模式教程](https://refactoringguru.cn/design-patterns/catalog)