🇨🇳🐲🎉 本网站的中文版本尚处早期开发阶段。如果您发现其中存在错字、纰漏或其他任何问题,请随时联系 support@refactoring.guru 向我反馈。
亦称: 封装器、­Wrapper、­Decorator

装饰

意图

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

装饰设计模式

问题

假设你正在开发一个提供通知功能的库,其他程序可使用它向用户发送关于重要事件的通知。

库的最初版本基于通知器(Notifier)类,其中只有很少的几个成员变量,一个构造方法和一个发送(send)方法。该方法可以接收来自客户端的消息参数,并将该消息发送给一系列的邮箱,邮箱列表则是通过构造方法传递给通知器的。作为客户端的第三方程序仅会创建和配置通知器对象一次,然后在有重要事件发生时对其进行调用。

使用装饰模式前的库结构

程序可以使用通知器类向一组预定义的邮箱发送重要事件通知。

此后某个时刻,你会发现库的用户希望使用除邮件通知之外的功能。许多用户会希望接收关于紧急事件的手机短信,还有些用户希望在微信上接收消息,而公司用户则希望在 QQ 上接收消息。

实现其他类型通知后的库结构

每种通知类型都将作为通知器的一个子类得以实现。

这有什么难的呢?首先扩展通知器类,然后在新的子类中加入额外的通知方法。现在客户端要对所需通知形式的对应类进行初始化,然后使用该类发送后续所有的通知消息。

但是很快有人会问:“为什么不同时使用多种通知形式呢?如果房子着火了,你大概会想在所有渠道中都收到相同的消息吧。”

你可以尝试创建一个特殊子类来将多种通知方法组合在一起以解决该问题。但这种方式会使得代码量迅速膨胀,不仅仅是程序库代码,客户端代码也会如此。

创建组合类后的程序库结构

子类组合数量爆炸。

你必须找到其他方法来规划通知类的结构,否则它们的数量会在不经意之间打破吉尼斯纪录。

解决方案

当你需要更改一个对象的行为时,第一个跳入脑海的想法就是扩展它所属的类。但是,你不能忽视继承可能引发的几个严重问题。

  • 继承是静态的。你无法在运行时更改已有对象的行为,只能使用由不同子类创建的对象来替代当前的整个对象。

  • 子类只能有一个父类。大部分编程语言不允许一个类同时继承多个类的行为。

其中一种方法是用​组合​替代​继承​。组合模式中的对象​包含​指向另一个对象的引用,并将部分工作委派给引用对象;继承中的对象则继承了父类的行为,它们自己​能够​完成这些工作。

你可以使用组合来轻松替换各种连接的“小帮手”对象,从而能在运行时改变容器的行为。一个对象可以使用多个类的行为,包含多个指向其他对象的引用,并将各种工作委派给引用对象。

组合是许多设计模式背后的关键原则(包括装饰在内)。记住这一点后,让我们继续关于模式的讨论。

继承与组合的对比

继承与组合的对比

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

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

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

装饰模式解决方案

将各种通知方法放入装饰。

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

程序可以配置由通知装饰构成的复杂栈

程序可以配置由通知装饰构成的复杂栈。

实际与客户端进行交互的对象将是最后一个进入栈中的装饰对象。由于所有的装饰都实现了与通知基类相同的接口,客户端的其他代码并不在意自己到底是与“纯粹”的通知器对象,还是与装饰后的通知器对象进行交互。

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

真实世界类比

装饰模式示例

穿上多件衣服将获得组合性的效果。

穿衣服是使用装饰的一个例子。觉得冷时,你可以穿一件毛衣。如果穿毛衣还觉得冷,你可以再套上一件夹克。如果遇到下雨,你还可以再穿一件雨衣。所有这些衣物都“扩展”了你的基本行为,但它们并不是你的一部分,如果你不再需要某件衣物,可以方便地随时脱掉。

结构

装饰设计模式的结构装饰设计模式的结构
  1. 部件(Component)声明封装器和被封装对象的公用接口。

  2. 具体部件(Concrete Component)类是被封装对象所属的类。它定义了基础行为,但装饰类可以改变这些行为。

  3. 基础装饰(Base Decorator)类拥有一个指向被封装对象的引用成员变量。该变量的类型应当被声明为通用部件接口,这样它就可以引用具体的部件和装饰。装饰基类会将所有操作委派给被封装的对象。

  4. 具体装饰类(Concrete Decorators)定义了可动态添加到部件的额外行为。具体装饰类会重写装饰基类的方法,并在调用父类方法之前或之后进行额外的行为。

  5. 客户端(Client)可以使用多层装饰来封装部件,只要它能使用通用接口与所有对象互动即可。

伪代码

在本例中,**装饰*模式能够对敏感数据进行压缩和加密,从而将数据从使用数据的代码中独立出来。

装饰模式示例的结构

加密和压缩装饰的示例。

程序使用一对装饰来封装数据源对象。这两个封装器都改变了从磁盘读写数据的方式:

  • 当数据即将被写入磁盘前,装饰对数据进行加密和压缩。原始类在对改变毫无察觉的情况下,将加密后的受保护数据写入文件。

  • 当数据刚从磁盘读出后,同样通过装饰对数据进行解压和解密。

装饰和数据源类实现同一接口,从而能在客户端代码中相互替换。

// The component interface defines operations that can be
// altered by decorators.
interface DataSource is
    method writeData(data)
    method readData():data

// Concrete components provide default implementations for the
// operations. There might be several variations of these
// classes in a program.
class FileDataSource implements DataSource is
    constructor FileDataSource(filename) { ... }

    method writeData(data) is
        // Write data to file.

    method readData():data is
        // Read data from file.

// The base decorator class follows the same interface as the
// other components. The primary purpose of this class is to
// define the wrapping interface for all concrete decorators.
// The default implementation of the wrapping code might include
// a field for storing a wrapped component and the means to
// initialize it.
class DataSourceDecorator implements DataSource is
    protected field wrappee: DataSource

    constructor DataSourceDecorator(source: DataSource) is
        wrappee = source

    // The base decorator simply delegates all work to the
    // wrapped component. Extra behaviors can be added in
    // concrete decorators.
    method writeData(data) is
        wrappee.writeData(data)

    // Concrete decorators may call the parent implementation of
    // the operation instead of calling the wrapped object
    // directly. This approach simplifies extension of decorator
    // classes.
    method readData():data is
        return wrappee.readData()

// Concrete decorators must call methods on the wrapped object,
// but may add something of their own to the result. Decorators
// can execute the added behavior either before or after the
// call to a wrapped object.
class EncryptionDecorator extends DataSourceDecorator is
    method writeData(data) is
        // 1. Encrypt passed data.
        // 2. Pass encrypted data to the wrappee's writeData
        // method.

    method readData():data is
        // 1. Get data from the wrappee's readData method.
        // 2. Try to decrypt it if it's encrypted.
        // 3. Return the result.

// You can wrap objects in several layers of decorators.
class CompressionDecorator extends DataSourceDecorator is
    method writeData(data) is
        // 1. Compress passed data.
        // 2. Pass compressed data to the wrappee's writeData
        // method.

    method readData():data is
        // 1. Get data from the wrappee's readData method.
        // 2. Try to decompress it if it's compressed.
        // 3. Return the result.


// Option 1. A simple example of a decorator assembly.
class Application is
    method dumbUsageExample() is
        source = new FileDataSource("somefile.dat")
        source.writeData(salaryRecords)
        // The target file has been written with plain data.

        source = new CompressionDecorator(source)
        source.writeData(salaryRecords)
        // The target file has been written with compressed
        // data.

        source = new EncryptionDecorator(source)
        // The source variable now contains this:
        // Encryption > Compression > FileDataSource
        source.writeData(salaryRecords)
        // The file has been written with compressed and
        // encrypted data.


// Option 2. Client code that uses an external data source.
// SalaryManager objects neither know nor care about data
// storage specifics. They work with a pre-configured data
// source received from the app configurator.
class SalaryManager is
    field source: DataSource

    constructor SalaryManager(source: DataSource) { ... }

    method load() is
        return source.readData()

    method save() is
        source.writeData(salaryRecords)
    // ...Other useful methods...


// The app can assemble different stacks of decorators at
// runtime, depending on the configuration or environment.
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()
    // ...

适用性

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

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

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

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

实现方式

  1. 确保业务逻辑可用一个基本组件及多个额外的可选层次来表示。

  2. 找出基本组件和可选层次的通用方法。创建一个组件接口并在其中声明这些方法。

  3. 创建一个具体组件类,并定义其基础行为。

  4. 创建装饰基类,使用一个成员变量存储指向被封装对象的引用。该成员变量必须被声明为组件接口类型,从而能在运行时连接具体组件和装饰。装饰基类必须将所有工作委派给被封装的对象。

  5. 确保所有类实现组件接口。

  6. 将装饰基类扩展为具体装饰。装饰必须在调用父类方法(总是委派给被封装对象)之前或之后执行自身的行为。

  7. 客户端代码负责创建装饰,并将其组合成为客户端所需的形式。

优缺点

  • 你无需创建新子类即可扩展对象的行为。
  • 你可以在运行时添加或删除对象的功能。
  • 你可以用多个装饰封装对象来组合几种行为。
  • [单一职责原则]。你可以将实现了许多不同行为的一个大类拆分为多个较小的类。
  • 在封装器栈中删除特定封装器比较困难。
  • 实现行为不受装饰栈顺序影响的装饰比较困难。
  • 各层的初始化配置代码看上去可能会很糟糕。

与其他模式的关系

  • 适配器可以对已有对象的接口进行修改,装饰则能在不改变对象接口的前提下强化对象功能。此外,​装饰​还支持递归组合,​适配器​则无法实现。

  • 适配器能为被封装对象提供不同的接口,代理能为对象提供相同的接口,装饰则能为对象提供加强的接口。

  • 职责链装饰模式的类结构非常相似。两者都依赖递归组合将需要执行的操作传递给一系列对象。但是,两者有几点重要的不同之处。

    职责链的管理者可以相互独立地执行一切操作,还可以随时停止传递请求。另一方面,各种​装饰​可以在遵循基础接口的情况下扩展对象的行为。此外,装饰无法中断请求的传递。

  • 组合装饰的结构图很相似,因为两者都依赖递归组合来组织无限数量的对象。

    装饰​类似于​组合​,但其只有一个子组件。此外还有一个明显不同:​装饰​为被封装对象添加了额外的职责,​组合​仅对其子节点的结果进行了“求和”。

    但是,模式也可以相互合作:你可以使用​装饰​来扩展​组合​树中特定对象的行为。

  • 大量使用组合装饰的设计通常可从对于原型的使用中获益。你可以通过该模式来复制复杂结构,而非从零开始重新构造。

  • 装饰可让你更改对象的外表,策略则让你能够改变其本质。

  • 装饰代理有着相似的结构,但是其意图却非常不同。这两个模式的构建都基于组合原则,也就是说一个对象应该将部分工作委派给另一个对象。两者之间的不同之处在于​代理​通常自行管理其服务对象的生命周期,而​装饰​的生成则总是由客户端进行控制。

在不同编程语言中的实现

装饰 在 Java 中的实现 装饰 在 C# 中的实现 装饰 在 PHP 中的实现 装饰 在 Python 中的实现 装饰 在 Ruby 中的实现 装饰 在 Swift 中的实现 装饰 在 TypeScript 中的实现