7.5.1.2 装饰设计模式（THE DECORATOR DESIGN PATTERN）

7.5.1.2 装饰设计模式（THE DECORATOR DESIGN PATTERN）

 

与复合模式相似的是装饰模式（decoratorpattern），这种模式的目标是，在运行时能够为已有的类添加新的行为。图 7.7 中可以看到，结构非常类似于复合模式。

这两个模式看起来相似，但目的完全不同的。复合模式的目的是把组合值与基本值同等对待，而装饰模式是为已有对象添加新的功能。从图 7.7 可以发现，DecoratedComponent类包装了一个别的装饰组件，能够携带额外的状态（例如 decoration 字段）。装饰组件也可以添加行为，在 Operation 方法中使用额外的状态。

图 7.7DecoratedComponent 类包装了一个组件，并给它添加新的状态；在装饰组件中的Operation 方法调用被包装的函数，并添加新的行为，使用装饰组件的状态。

 

在我们的文档表示形式中，还可以看到这种模式与文档部分之间的对应。在我们的应用程序中，添加装饰到其他部分的是 TitledPart 部分。装饰是标题，添加的状态是文本和标题的字体。表示如图 7.7 同样结构的F# 类型，也与复合模式的情况一样简单：

 

type AbstractComponent = 

  | DecoratedComponent ofAbstractComponent * (...) 

  | ConcreteComponent of (...) 

  | (...)

 

在这里，由装饰选项携带的数据是装饰过的组件（不是复合模式中的组件列表），和额外的状态，它可以在不同的装饰之间改变。在前面的清单中，我们使用 (...) 语法来表示，这只是伪代码；在真正 F# 代码中，这里可以指定实际状态的类型，比如，带标题部分中的 TextContent。正如复合模式，在装饰组件上实现操作的代码，位于处理函数中，为我们实现数据结构。在处理函数中，DecoratedComponent 分支的代码能够递归调用自已，处理包装的组件，执行由该装饰添加的行为，比如，绘制文档部分的标题。

在这一节，F# 实现的两种模式都依赖于使用递归的差别联合类型；在下一节，我们会以不同的方式使用，用面向对象的方法，为已有的数据类型添加新的操作。