# 扩展系统功能——装饰模式(一)
尽管目前房价依旧很高,但还是阻止不了大家对新房的渴望和买房的热情。如果大家买的是毛坯房,无疑还有一项艰巨的任务要面对,那就是装修。对新房进行装修并没有改变房屋用于居住的本质,但它可以让房子变得更漂亮、更温馨、更实用、更能满足居家的需求。在软件设计中,我们也有一种类似新房装修的技术可以对已有对象(新房)的功能进行扩展(装修),以获得更加符合用户需求的对象,使得对象具有更加强大的功能。这种技术对应于一种被称之为装饰模式的设计模式,本章将介绍用于扩展系统功能的装饰模式。
12.1 图形界面构件库的设计
Sunny软件公司基于面向对象技术开发了一套图形界面构件库VisualComponent,该构件库提供了大量基本构件,如窗体、文本框、列表框等,由于在使用该构件库时,用户经常要求定制一些特效显示效果,如带滚动条的窗体、带黑色边框的文本框、既带滚动条又带黑色边框的列表框等等,因此经常需要对该构件库进行扩展以增强其功能,如图12-1所示:
![](http://my.csdn.net/uploads/201204/03/1333467488_9122.gif)
图12-1 带滚动条的窗体示意图
如何提高图形界面构件库性的可扩展性并降低其维护成本是Sunny公司开发人员必须面对的一个问题。
Sunny软件公司的开发人员针对上述要求,提出了一个基于继承复用的初始设计方案,其基本结构如图12-2所示:
![](http://my.csdn.net/uploads/201204/03/1333467493_2167.gif)
图12-2 图形界面构件库初始设计方案
图12-2中,在抽象类Component中声明了抽象方法display(),其子类Window、TextBox等实现了display()方法,可以显示最简单的控件,再通过它们的子类来对功能进行扩展,例如,在Window的子类ScrollBarWindow、BlackBorderWindow中对Window中的display()方法进行扩展,分别实现带滚动条和带黑色边框的窗体。仔细分析该设计方案,我们不难发现存在如下几个问题:
(1) 系统扩展麻烦,在某些编程语言中无法实现。如果用户需要一个既带滚动条又带黑色边框的窗体,在图12-2中通过增加了一个新的类ScrollBarAndBlackBorderWindow来实现,该类既作为ScrollBarWindow的子类,又作为BlackBorderWindow的子类;但现在很多面向对象编程语言,如Java、C#等都不支持多重类继承,因此在这些语言中无法通过继承来实现对来自多个父类的方法的重用。此外,如果还需要扩展一项功能,例如增加一个透明窗体类TransparentWindow,它是Window类的子类,可以将一个窗体设置为透明窗体,现在需要一个同时拥有三项功能(带滚动条、带黑色边框、透明)的窗体,必须再增加一个类作为三个窗体类的子类,这同样在Java等语言中无法实现。系统在扩展时非常麻烦,有时候甚至无法实现。
(2)代码重复。从图12-2中我们可以看出,不只是窗体需要设置滚动条,文本框、列表框等都需要设置滚动条,因此在ScrollBarWindow、ScrollBarTextBox和ScrollBarListBox等类中都包含用于增加滚动条的方法setScrollBar(),该方法的具体实现过程基本相同,代码重复,不利于对系统进行修改和维护。
(3) 系统庞大,类的数目非常多。如果增加新的控件或者新的扩展功能系统都需要增加大量的具体类,这将导致系统变得非常庞大。在图12-2中,3种基本控件和2种扩展方式需要定义9个具体类;如果再增加一个基本控件还需要增加3个具体类;增加一种扩展方式则需要增加更多的类,如果存在3种扩展方式,对于每一个控件而言,需要增加7个具体类,因为这3种扩展方式存在7种组合关系(大家自己分析为什么需要7个类?)。
总之,图12-2不是一个好的设计方案,怎么办?如何让系统中的类可以进行扩展但是又不会导致类数目的急剧增加?不用着急,让我们先来分析为什么这个设计方案会存在如此多的问题。根本原因在于复用机制的不合理,图12-2采用了继承复用,例如在ScrollBarWindow中需要复用Window类中定义的display()方法,同时又增加新的方法setScrollBar(),ScrollBarTextBox和ScrollBarListBox都必须做类似的处理,在复用父类的方法后再增加新的方法来扩展功能。根据“合成复用原则”,在实现功能复用时,我们要多用关联,少用继承,因此我们可以换个角度来考虑,将setScrollBar()方法抽取出来,封装在一个独立的类中,在这个类中定义一个Component类型的对象,通过调用Component的display()方法来显示最基本的构件,同时再通过setScrollBar()方法对基本构件的功能进行增强。由于Window、ListBox和TextBox都是Component的子类,根据“里氏代换原则”,程序在运行时,我们只要向这个独立的类中注入具体的Component子类的对象即可实现功能的扩展。这个独立的类一般称为装饰器(Decorator)或装饰类,顾名思义,它的作用就是对原有对象进行装饰,通过装饰来扩展原有对象的功能。
装饰类的引入将大大简化本系统的设计,它也是装饰模式的核心,下面让我们正式进入装饰模式的学习。
- Introduction
- 基础知识
- 设计模式概述
- 从招式与内功谈起——设计模式概述(一)
- 从招式与内功谈起——设计模式概述(二)
- 从招式与内功谈起——设计模式概述(三)
- 面向对象设计原则
- 面向对象设计原则之单一职责原则
- 面向对象设计原则之开闭原则
- 面向对象设计原则之里氏代换原则
- 面向对象设计原则之依赖倒转原则
- 面向对象设计原则之接口隔离原则
- 面向对象设计原则之合成复用原则
- 面向对象设计原则之迪米特法则
- 六个创建型模式
- 简单工厂模式-Simple Factory Pattern
- 工厂三兄弟之简单工厂模式(一)
- 工厂三兄弟之简单工厂模式(二)
- 工厂三兄弟之简单工厂模式(三)
- 工厂三兄弟之简单工厂模式(四)
- 工厂方法模式-Factory Method Pattern
- 工厂三兄弟之工厂方法模式(一)
- 工厂三兄弟之工厂方法模式(二)
- 工厂三兄弟之工厂方法模式(三)
- 工厂三兄弟之工厂方法模式(四)
- 抽象工厂模式-Abstract Factory Pattern
- 工厂三兄弟之抽象工厂模式(一)
- 工厂三兄弟之抽象工厂模式(二)
- 工厂三兄弟之抽象工厂模式(三)
- 工厂三兄弟之抽象工厂模式(四)
- 工厂三兄弟之抽象工厂模式(五)
- 单例模式-Singleton Pattern
- 确保对象的唯一性——单例模式 (一)
- 确保对象的唯一性——单例模式 (二)
- 确保对象的唯一性——单例模式 (三)
- 确保对象的唯一性——单例模式 (四)
- 确保对象的唯一性——单例模式 (五)
- 原型模式-Prototype Pattern
- 对象的克隆——原型模式(一)
- 对象的克隆——原型模式(二)
- 对象的克隆——原型模式(三)
- 对象的克隆——原型模式(四)
- 建造者模式-Builder Pattern
- 复杂对象的组装与创建——建造者模式(一)
- 复杂对象的组装与创建——建造者模式(二)
- 复杂对象的组装与创建——建造者模式(三)
- 七个结构型模式
- 适配器模式-Adapter Pattern
- 不兼容结构的协调——适配器模式(一)
- 不兼容结构的协调——适配器模式(二)
- 不兼容结构的协调——适配器模式(三)
- 不兼容结构的协调——适配器模式(四)
- 桥接模式-Bridge Pattern
- 处理多维度变化——桥接模式(一)
- 处理多维度变化——桥接模式(二)
- 处理多维度变化——桥接模式(三)
- 处理多维度变化——桥接模式(四)
- 组合模式-Composite Pattern
- 树形结构的处理——组合模式(一)
- 树形结构的处理——组合模式(二)
- 树形结构的处理——组合模式(三)
- 树形结构的处理——组合模式(四)
- 树形结构的处理——组合模式(五)
- 装饰模式-Decorator Pattern
- 扩展系统功能——装饰模式(一)
- 扩展系统功能——装饰模式(二)
- 扩展系统功能——装饰模式(三)
- 扩展系统功能——装饰模式(四)
- 外观模式-Facade Pattern
- 深入浅出外观模式(一)
- 深入浅出外观模式(二)
- 深入浅出外观模式(三)
- 享元模式-Flyweight Pattern
- 实现对象的复用——享元模式(一)
- 实现对象的复用——享元模式(二)
- 实现对象的复用——享元模式(三)
- 实现对象的复用——享元模式(四)
- 实现对象的复用——享元模式(五)
- 代理模式-Proxy Pattern
- 设计模式之代理模式(一)
- 设计模式之代理模式(二)
- 设计模式之代理模式(三)
- 设计模式之代理模式(四)
- 十一个行为型模式
- 职责链模式-Chain of Responsibility Pattern
- 请求的链式处理——职责链模式(一)
- 请求的链式处理——职责链模式(二)
- 请求的链式处理——职责链模式(三)
- 请求的链式处理——职责链模式(四)
- 命令模式-Command Pattern
- 请求发送者与接收者解耦——命令模式(一)
- 请求发送者与接收者解耦——命令模式(二)
- 请求发送者与接收者解耦——命令模式(三)
- 请求发送者与接收者解耦——命令模式(四)
- 请求发送者与接收者解耦——命令模式(五)
- 请求发送者与接收者解耦——命令模式(六)
- 解释器模式-Interpreter Pattern
- 自定义语言的实现——解释器模式(一)
- 自定义语言的实现——解释器模式(二)
- 自定义语言的实现——解释器模式(三)
- 自定义语言的实现——解释器模式(四)
- 自定义语言的实现——解释器模式(五)
- 自定义语言的实现——解释器模式(六)
- 迭代器模式-Iterator Pattern
- 遍历聚合对象中的元素——迭代器模式(一)
- 遍历聚合对象中的元素——迭代器模式(二)
- 遍历聚合对象中的元素——迭代器模式(三)
- 遍历聚合对象中的元素——迭代器模式(四)
- 遍历聚合对象中的元素——迭代器模式(五)
- 遍历聚合对象中的元素——迭代器模式(六)
- 中介者模式-Mediator Pattern
- 协调多个对象之间的交互——中介者模式(一)
- 协调多个对象之间的交互——中介者模式(二)
- 协调多个对象之间的交互——中介者模式(三)
- 协调多个对象之间的交互——中介者模式(四)
- 协调多个对象之间的交互——中介者模式(五)
- 备忘录模式-Memento Pattern
- 撤销功能的实现——备忘录模式(一)
- 撤销功能的实现——备忘录模式(二)
- 撤销功能的实现——备忘录模式(三)
- 撤销功能的实现——备忘录模式(四)
- 撤销功能的实现——备忘录模式(五)
- 观察者模式-Observer Pattern
- 对象间的联动——观察者模式(一)
- 对象间的联动——观察者模式(二)
- 对象间的联动——观察者模式(三)
- 对象间的联动——观察者模式(四)
- 对象间的联动——观察者模式(五)
- 对象间的联动——观察者模式(六)
- 状态模式-State Pattern
- 处理对象的多种状态及其相互转换——状态模式(一)
- 处理对象的多种状态及其相互转换——状态模式(二)
- 处理对象的多种状态及其相互转换——状态模式(三)
- 处理对象的多种状态及其相互转换——状态模式(四)
- 处理对象的多种状态及其相互转换——状态模式(五)
- 处理对象的多种状态及其相互转换——状态模式(六)
- 策略模式-Strategy Pattern
- 算法的封装与切换——策略模式(一)
- 算法的封装与切换——策略模式(二)
- 算法的封装与切换——策略模式(三)
- 算法的封装与切换——策略模式(四)
- 模板方法模式-Template Method Pattern
- 模板方法模式深度解析(一)
- 模板方法模式深度解析(二)
- 模板方法模式深度解析(三)
- 访问者模式-Visitor Pattern
- 操作复杂对象结构——访问者模式(一)
- 操作复杂对象结构——访问者模式(二)
- 操作复杂对象结构——访问者模式(三)
- 操作复杂对象结构——访问者模式(四)
- 设计模式趣味学习(复习)
- 设计模式与足球(一)
- 设计模式与足球(二)
- 设计模式与足球(三)
- 设计模式与足球(四)
- 设计模式综合应用实例
- 多人联机射击游戏
- 多人联机射击游戏中的设计模式应用(一)
- 多人联机射击游戏中的设计模式应用(二)
- 数据库同步系统
- 设计模式综合实例分析之数据库同步系统(一)
- 设计模式综合实例分析之数据库同步系统(二)
- 设计模式综合实例分析之数据库同步系统(三)