GOF设计模式-对象结构型模式-装饰模式

拓展系统功能-装饰模式

尽管目前房价依旧很高，但还是阻止不了大家对新房的渴望和买房的热情。如果大家买的是 毛坯房，无疑还有一项艰巨的任务要面对，那就是装修。对新房进行装修并没有改变房屋用 于居住的本质，但它可以让房子变得更漂亮、更温馨、更实用、更能满足居家的需求。在软 件设计中，我们也有一种类似新房装修的技术可以对已有对象（新房）的功能进行扩展（装 修），以获得更加符合用户需求的对象，使得对象具有更加强大的功能。这种技术对应于一 种被称之为装饰模式的设计模式，本章将介绍用于扩展系统功能的装饰模式。

举个栗子：

软件公司基于面向对象技术开发了一套图形界面构件库VisualComponent，该构件库提供 了大量基本构件，如窗体、文本框、列表框等，由于在使用该构件库时，用户经常要求定制 一些特效显示效果，如带滚动条的窗体、带黑色边框的文本框、既带滚动条又带黑色边框的 列表框等等，因此经常需要对该构件库进行扩展以增强其功能：

如何提高图形界面构件库性的可扩展性并降低其维护成本是Sunny公司开发人员必须面对的一 个问题。 Sunny软件公司的开发人员针对上述要求，提出了一个基于继承复用的初始设计方案，其基本 结构如图：（反面教材）

在抽象类Component中声明了抽象方法display()，其子类Window、TextBox等实现了 display()方法，可以显示最简单的控件，再通过它们的子类来对功能进行扩展，例如，在 Window的子类ScrollBarWindow、BlackBorderWindow中对Window中的display()方法进行扩 展，分别实现带滚动条和带黑色边框的窗体。仔细分析该设计方案，我们不难发现存在如下 几个问题：

(1) 系统扩展麻烦，在某些编程语言中无法实现。如果用户需要一个既带滚动条又带黑色边框 的窗体，在图中通过增加了一个新的类ScrollBarAndBlackBorderWindow来实现，该类既作 为ScrollBarWindow的子类，又作为BlackBorderWindow的子类；但现在很多面向对象编程语 言，如Java、C#等都不支持多重类继承，因此在这些语言中无法通过继承来实现对来自多个 父类的方法的重用。此外，如果还需要扩展一项功能，例如增加一个透明窗体类 TransparentWindow，它是Window类的子类，可以将一个窗体设置为透明窗体，现在需要一个 同时拥有三项功能（带滚动条、带黑色边框、透明）的窗体，必须再增加一个类作为三个窗 体类的子类，这同样在Java等语言中无法实现。系统在扩展时非常麻烦，有时候甚至无法实 现。

(2)代码重复。从图中我们可以看出，不只是窗体需要设置滚动条，文本框、列表框等都 需要设置滚动条，因此在ScrollBarWindow、ScrollBarTextBox和ScrollBarListBox等类中都包含 用于增加滚动条的方法setScrollBar()，该方法的具体实现过程基本相同，代码重复，不利于对 系统进行修改和维护。

(3) 系统庞大，类的数目非常多。如果增加新的控件或者新的扩展功能系统都需要增加大量的 具体类，这将导致系统变得非常庞大。在图中，3种基本控件和2种扩展方式需要定义9个 具体类；如果再增加一个基本控件还需要增加3个具体类；增加一种扩展方式则需要增加更多 的类，如果存在3种扩展方式，对于每一个控件而言，需要增加7个具体类，因为这3种扩展方 式存在7种组合关系（大家自己分析为什么需要7个类？）。

 xa  xb  xc  xab  xac  xbc  xabc

怎么办？装饰模式为此业务场景量身打造；

 

装饰模式概述

 

装饰模式可以在不改变一个对象本身功能的基础上给对象增加额外的新行为，在现实生活 中，这种情况也到处存在，例如一张照片，我们可以不改变照片本身，给它增加一个相框， 使得它具有防潮的功能，而且用户可以根据需要给它增加不同类型的相框，甚至可以在一个 小相框的外面再套一个大相框。 装饰模式是一种用于替代继承的技术，它通过一种无须定义子类的方式来给对象动态增加职 责，使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类，在装饰 类中既可以调用待装饰的原有类的方法，还可以增加新的方法，以扩充原有类的功能。

装饰模式定义如下： 装饰模式(Decorator Pattern)：动态地给一个对象增加一些额外的职责，就增加对象功能来说， 装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。

在装饰模式中，为了让系统具有更好的灵活性和可扩展性，我们通常会定义一个抽象装饰 类，而将具体的装饰类作为它的子类，装饰模式结构如图：

 

在装饰模式结构图中包含如下几个角色：

● Component（抽象构件）：它是具体构件和抽象装饰类的共同父类，声明了在具体构件中实 现的业务方法，它的引入可以使客户端以一致的方式处理未被装饰的对象以及装饰之后的对 象，实现客户端的透明操作。

● ConcreteComponent（具体构件）：它是抽象构件类的子类，用于定义具体的构件对象，实 现了在抽象构件中声明的方法，装饰器可以给它增加额外的职责（方法）。

● Decorator（抽象装饰类）：它也是抽象构件类的子类，用于给具体构件增加职责，但是具体 职责在其子类中实现。它维护一个指向抽象构件对象的引用，通过该引用可以调用装饰之前 构件对象的方法，并通过其子类扩展该方法，以达到装饰的目的。

● ConcreteDecorator（具体装饰类）：它是抽象装饰类的子类，负责向构件添加新的职责。每 一个具体装饰类都定义了一些新的行为，它可以调用在抽象装饰类中定义的方法，并可以增 加新的方法用以扩充对象的行为。

由于具体构件类和装饰类都实现了相同的抽象构件接口，因此装饰模式以对客户透明的方式 动态地给一个对象附加上更多的责任，换言之，客户端并不会觉得对象在装饰前和装饰后有 什么不同。装饰模式可以在不需要创造更多子类的情况下，将对象的功能加以扩展。

完整解决方案：

 

装饰模式的核心在于抽象装饰类的设计，其典型代码如下所示：

 为了让系统具有更好的灵活性和可扩展性，克服继承复用所带来的问题，Sunny公司开发人员 使用装饰模式来重构图形界面构件库的设计，其中部分类的基本结构如图

，Component充当抽象构件类，其子类Window、TextBox、ListBox充当具体构件 类，Component类的另一个子类ComponentDecorator充当抽象装饰类，ComponentDecorator的 子类ScrollBarDecorator和BlackBorderDecorator充当具体装饰类。完整代码如下所示：

//抽象界面构件类：抽象构件类，为了突出与模式相关的核心代码，对原有控件代码进行了大量的简化 abstract class Component { public abstract void display(); } //窗体类：具体构件类 class Window extends Component { public void display() { System.out.println("显示窗体！"); } } //文本框类：具体构件类 class TextBox extends Component { public void display() { System.out.println("显示文本框！"); } } //列表框类：具体构件类 class ListBox extends Component { public void display() { System.out.println("显示列表框！"); } } //构件装饰类：抽象装饰类 class ComponentDecorator extends Component { private Component component; //维持对抽象构件类型对象的引用 public ComponentDecorator(Component component) //注入抽象构件类型的对象 { this.component = component; } public void display() { component.display(); } } //滚动条装饰类：具体装饰类 class ScrollBarDecorator extends ComponentDecorator { public ScrollBarDecorator(Component component) { super(component); } public void display() { this.setScrollBar(); super.display(); } public void setScrollBar() { System.out.println("为构件增加滚动条！"); } } //黑色边框装饰类：具体装饰类 class BlackBorderDecorator extends ComponentDecorator { public BlackBorderDecorator(Component component) { super(component); } public void display() { this.setBlackBorder(); super.display(); } public void setBlackBorder() { System.out.println("为构件增加黑色边框！"); } } //编写如下客户端测试代码： class Client { public static void main(String args[]) { Component component, componentSB; //使用抽象构件定义 component = new Window(); //定义具体构件 componentSB = new ScrollBarDecorator(component); //定义装饰后的构 componentSB.display(); } }

 

编译并运行程序，输出结果如下：
为构件增加滚动条！ 显示窗体！

在客户端代码中，我们先定义了一个Window类型的具体构件对象component，然后将 component作为构造函数的参数注入到具体装饰类ScrollBarDecorator中，得到一个装饰之后对 象componentSB，再调用componentSB的display()方法后将得到一个有滚动条的窗体。如果我们 希望得到一个既有滚动条又有黑色边框的窗体，不需要对原有类库进行任何修改，只需将客 户端代码修改为如下所示：

class Client { public static void main(String args[]) { Component component, componentSB, componentBB; //全部使用抽象构件定义 component = new Window(); componentSB = new ScrollBarDecorator(component); componentBB = new BlackBorderDecorator(componentSB); //将装饰了一 componentBB.display(); } }

编译并运行程序，输出结果如下：
为构件增加黑色边框！

为构件增加滚动条！

显示窗体！
我们可以将装饰了一次之后的componentSB对象注入另一个装饰类BlackBorderDecorator中实现 第二次装饰，得到一个经过两次装饰的对象componentBB，再调用componentBB的display()方 法即可得到一个既有滚动条又有黑色边框的窗体。
如果需要在原有系统中增加一个新的具体构件类或者新的具体装饰类，无须修改现有类库代 码，只需将它们分别作为抽象构件类或者抽象装饰类的子类即可。与图12-2所示的继承结构相 比，使用装饰模式之后将大大减少了子类的个数，让系统扩展起来更加方便，而且更容易维 护，是取代继承复用的有效方式之一。

装饰模式总结

装饰模式降低了系统的耦合度，可以动态增加或删除对象的职责，并使得需要装饰的具体构 件类和具体装饰类可以独立变化，以便增加新的具体构件类和具体装饰类。在软件开发中， 装饰模式应用较为广泛，例如在JavaIO中的输入流和输出流的设计、javax.swing包中一些图形 界面构件功能的增强等地方都运用了装饰模式。

装饰模式的主要优点如下：

(1) 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。
(2) 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的 具体装饰类，从而实现不同的行为。
(3) 可以对一个对象进行多次装饰，通过使用不同的具体装饰类以及这些装饰类的排列组合， 可以创造出很多不同行为的组合，得到功能更为强大的对象。
(4) 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装 饰类，原有类库代码无须改变，符合“开闭原则”。

装饰模式的主要缺点如下：

(1) 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接 的方式有所不同，而不是它们的类或者属性值有所不同，大量小对象的产生势必会占用更多 的系统资源，在一定程序上影响程序的性能。
(2) 装饰模式提供了一种比继承更加灵活机动的解决方案，但同时也意味着比继承更加易于出 错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为繁琐。

在以下情况下可以考虑使用装饰模式：

(1) 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
(2) 当不能采用继承的方式对系统进行扩展或者采用继承不利于系统扩展和维护时可以使用装 饰模式。不能采用继承的情况主要有两类：第一类是系统中存在大量独立的扩展，为支持每 一种扩展或者扩展之间的组合将产生大量的子类，使得子类数目呈爆炸性增长；第二类是因 为类已定义为不能被继承（如Java语言中的final类）。