设计模式之装饰者模式(Decorator Pattern)——惯用继承思考者的另类路径

装饰者模式

装饰模式是一种结构型设计模式， 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为。

装饰指在某物件上装点额外饰品的行为，以使其原本朴素的外表变得更加饱满、华丽，而装饰器（装饰者）就是能够化“腐朽”为神奇的利器。

问题分析

假设你是大学里一个恶臭的辅导员，辅导员需要你开发一个通知的聚合程序，这个程序可以进行各种手段去通知你参加活动（微信、QQ、短信、邮箱…）。
开始思考，该程序所有的最初版本都基于通知器Notifier类，只有很少的成员变量。一个构造函数，一个发送通知的send方法。对于发送通知的方法可以接受到来客户端的消息参数，并将该消息发送给一系列的QQ，QQ列表则是通过构造函数传递给通知器的。

之后，用同学就开始发表不满，我都没接到通知，而且QQ从来不用。你会发现，为了让学生一定要收到辅导员的通知，有些同学可能希望通过微信，有些可能希望通过邮箱，有些可能…。
你一想，这有什么难的呢？ 首先扩展 通知器类， 然后在新的子类中加入额外的通知方法。 现在客户端要对所需通知形式的对应类进行初始化， 然后使用该类发送后续所有的通知消息。

但是恶臭的辅导员说，能不能让同学可以同时收到QQ，邮箱或者是微信或者是手机短信？

我一想，可以，没问题…然后我就设计了下面这种。

给每一种情况都加上了对应的通知类，一共有16个，不算太累。后面有同学说，我有时候只会收到抖音的通知，我有时候只会收到陌陌的通知…

通过这种方式，会使得代码量迅速膨胀， 不仅仅是程序库代码， 客户端代码也会如此。必须找到其他方法来规划通知类的结构， 否则它们的数量可能会出现指数爆炸的情况。

解决方案

当你需要更改一个对象的行为时， 第一个想法就是扩展它所属的类。 但是， 你不能忽视继承可能引发的几个严重问题，不然就会和上面所定义的通知类一样。

• 继承是静态的。 你无法在运行时更改已有对象的行为， 只能使用由不同子类创建的对象来替代当前的整个对象。
• 子类只能有一个父类。 大部分编程语言不允许一个类同时继承多个类的行为。

其中一种方法是用聚合或组合 ， 而不是继承。 两者的工作方式几乎一模一样： 一个对象包含指向另一个对象的引用， 并将部分工作委派给引用对象； 继承中的对象则继承了父类的行为， 它们自己能够完成这些工作

实际上很多设计模式都是通过这种方法（聚合或组合）来替换各种连接，最终达到程序解耦的效果。
继承和聚合的对别图：

封装器是装饰模式的别称， 这个称谓明确地表达了该模式的主要思想。 ​ “封装器” 是一个能与其他 “目标” 对象连接的对象。 封装器包含与目标对象相同的一系列方法， 它会将所有接收到的请求委派给目标对象。 但是， 封装器可以在将请求委派给目标前后对其进行处理， 所以可能会改变最终结果。

那么什么时候一个简单的封装器可以被称为是真正的装饰呢？ 正如之前提到的， 封装器实现了与其封装对象相同的接口。 因此从客户端的角度来看， 这些对象是完全一样的。 封装器中的引用成员变量可以是遵循相同接口的任意对象。 这使得你可以将一个对象放入多个封装器中， 并在对象中添加所有这些封装器的组合行为。

比如在消息通知示例中， 我们可以将简单邮件通知行为放在基类 通知器中， 但将所有其他通知方法放入装饰中。

客户端代码必须将基础通知器放入一系列自己所需的装饰中。 因此最后的对象将形成一个栈结构。

我们可以使用相同方法来完成其他行为 （例如设置消息格式或者创建接收人列表）。 只要所有装饰都遵循相同的接口， 客户端就可以使用任意自定义的装饰来装饰对象。

装饰模式结构

真实的设计案例

1. 自定义编码器

假设我们要设计的是如下：
当数据即将被写入磁盘前， 装饰对数据进行加密和压缩。 在原始类对改变毫无察觉的情况下， 将加密后的受保护数据写入文件。当数据刚从磁盘读出后， 同样通过装饰对数据进行解压和解密。装饰和数据源类实现同一接口， 从而能在客户端代码中相互替换

接下来看看伪代码如何写：

// 装饰可以改变组件接口所定义的操作。
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()
    // ……

具体的代码实现我放到了github中:
https://github.com/fckey/Design_patterns_Examples/tree/master/src/main/java/com/fckey/design/decorators

2. Java设计中的装饰者模式

​ 还记得如何从一个控制台读取一行字符串吗？

 BufferedReader bufferedReader = new BufferedReader( new InputStreamReader( System.in ) );
        try {
            System.out.println( bufferedReader.readLine());
            bufferedReader.close();
        } catch (IOException e) {
            e.printStackTrace();
        }

在java IO中，这种形式new xx(new xxx(new xxxx( new xxxxxx())))似乎很常见。事实上，他们都来继承自抽象类InputStream。下面将简单介绍一下InputStream。

这里也使用了装饰者的设计模式。具体查看：https://blog.csdn.net/hqing159/article/details/76827873

装饰模式适合应用场景

1. 如果你希望在无需修改代码的情况下即可使用对象， 且希望在运行时为对象新增额外的行为， 可以使用装饰模式。

2. 装饰能将业务逻辑组织为层次结构， 你可为各层创建一个装饰， 在运行时将各种不同逻辑组合成对象。 由于这些对象都遵循通用接口， 客户端代码能以相同的方式使用这些对象。

3. 如果用继承来扩展对象行为的方案难以实现或者根本不可行， 你可以使用该模式。

4. 许多编程语言使用 final最终关键字来限制对某个类的进一步扩展。 复用最终类已有行为的唯一方法是使用装饰模式： 用封装器对其进行封装。

优缺点