系统分析与设计论文

软件设计模式的研究及应用

摘要：设计模式记录己知的反复出现的问题，以及在特定上下文中对该问题的解决方案。设计模式构成了强大的复用机制，在快速的需求变化面前，有利于解决软件的开发成本高，质量不够理想，后期软件修改与维护困难、总体成功率不高等问题。本文主要对设计模式的关键技术展开研究，综述了面向对象软件的各种设计模式，描述了各种模式之间的关系以及它们在软件，设计过程中的使用，并对设计模式的进一步发展作了展望。在系统开发中应用设计模式所获得的收益是显著的，应用设计模式解决具体的设计问题的趋势是普遍的。设计模式给出的解决方案具有更好的复用性、可扩展性和维护性，采用设计模式的应用系统更能满足这些非功能需求。

关键字：设计模式；面向对象；复用

1引言

设计模式并不只出现在面向对象的系统中，因此设计模式本身并不局限于面向对象设计的范畴，也不局限于某一种编程语言。但鉴于面向对象技术的成熟和广泛应用以及本文所在的项目小组的实际情况，本文中的设计模式仅限于面向对象的设计模式。

20世纪60年代爆发了“软件危机”，采用传统的软件开发方法往往导致软件质量差，可靠性不能得到保证，软件成本增长居高不下，软件的开发进度难以控制，软件开发周期长，维护困难，维护费用不断增加。这些弱点逐渐被人们认识到，并开始寻找新的软件开发方法。面向对象的软件开发方法首先提出于20世纪60年代后期，之后经过了几乎20年的时间，对象技术开始得到广泛应用。在20世纪90年代，面向对象软件工程成为了很多开发软件产品及信息系统首选的软件开发技术和方法。对象技术导致了复用，而程序构件的复用又导致了更快的软件开发和高质量的程序。复用为解决“软件危机”提供了一种有效的途径。

但是，人们也认识到要设计面向对象的软件是比较困难的，要设计可以复用的面向对象的软件就更加困难。而面向对象软件的设计专家在几十年的设计工作中己经积累了相当多的设计经验，如果能在后续的面向对象的软件设计中充分利用这些设计经验，将有助于人们设计出好的甚至是可以良好复用的面向对象的软件系统。幸运的是，设计模式能够帮助软件工作者，它是被记录下来的面向对象的软件设计经验，这些设计已被证实是优雅的，成功的和易于复用的。

2设计模式概述

2.1设计模式的概念

关于设计模式的定义有很多种，本文仅列出了几个具有代表性的、权威性的定义：

定义1：Alexander给出的经典定义是：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次的使用该方案而不必做重

-1-

复劳动。

定义2：GoF的《设计模式》中这样描述：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。这是面向对象的设计模式，也是本文研究的对象。尽管设计模式不限于面向对象，不限于设计阶段，甚至不限于软件开发领域，但说明这一点是必要的。

定义3：模式是被命名的有组织的信息，它捕获了在一定语境（场景）中包含相关作用力的问题的解决方案的本质结构和内在含义，这种解决方案被证明是成功的。这样的定义包含三部分：相关的上下文、与上下文相关的作用力系统和解决问题的方案。从模式的这个定义可以看出，只有相关上下文和各种作用力完全符合时，模式中的解决方案才是最优的方案。也就是说，模式是一种在权衡了各种利弊后的解决方案，一旦作用力之间的平衡被打破，这个解决方案就可能不再成立。

定义4：设计模式提供一个用于细化软件系统的子系统或组件，或它们之间关系的图式。它描述通用组件的公共再现结构，通用组件可以解决特定语境中的一个一般设计问题。设计模式是中等规模的模式。它们在规模上比体系结构模式小，但又独立于特定编程语言和范例。

2.2设计模式的要素

一般而言，一个模式有四个基本要素。

（l）模式名称（Patten Name）一个助记名，它用一两个词来描述模式的问题、解决方案和效果。命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。找到恰当的模式名也是我们设计模式编目工作的难点之一。

（2）问题（Problem）描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。

（3）解决方案（Solution）描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。

（4）效果（Consequences）描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总提到模式效果，但它们对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们也表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些模式很有帮助。

3设计模式分类

软件设计模式的分类有不同的方法。本文主要参考文献[1]来进行分类。根据模式是用来

-2-

完成什么工作的不同，可将设计模式分为创建型模式、结构型模式、行为型模式三种。根

据模式是用于类还是用于对象，可将其分为类模式和对象模式。类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来；对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具有动态性。

3.1创建型设计模式

创建型模式与对象的创建有关，即描述怎样创建一个对象，它隐藏对象创建的具体细节，使程序代码不依赖具体的对象。因此当我们增加一个新对象时几乎不需要修改代码即可。创建型类模式将对象的部分创建工作延迟到子类，而创建型对象模式则将它延迟到另一个对象中。创建型类模式有Factory Method（工厂方法）模式，创建型对象模式包Abstract Factory （抽象工厂）、Builder（生成器）、Prototype（原型）、Singleton（单件）四种模式。创建型模式中，Abstract Factory由工厂对象产生多个类的对象；Builder是由这个工厂对象使用一个相对复杂的协议，逐步创建一个相对复杂的产品；Prototype是由该工厂对象通过拷贝原型对象来创建产品对象；Singleton确保一个类只创建一个实例；Factory Method是先生成所要创建的对象的类的子类，即由其子类进行实例化创建对象。

上述模式中，Abstract Factory与Factory Method的关系是：Abstract Factory仅声明一个创建Product（产品）的接口，真正创建Product是由AbstractProduct类的子类ConcreteProduct 类来实现，实现办法通常是为每一个Product定义一个Factory Method，而一个ConcreteFactory（具体的工厂）将为每个产品重定义Factory Method以指定产品。当然Abstract Factory中的ConcreteFactory也可以用Prototype模式来实现，即具体工厂使用产品系列中每一个产品的原型实例来初始化，再通过复制原型来创建新产品；Abstract Factory与Builder 的区别是：Builder模式着重一步步构造一个复杂对象，并在最后一步返回产品，而Abstract Factory着重于多个系列的产品对象，其产品是立即可见的。

例如：单件模式也称为单例模式、单子模式，是使用最广泛的设计模式之一。其意图是保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。有很多地方需要这样的功能模块，如系统的日志输出，GUI应用必须是单鼠标，MODEM的联接需要一条且只需要一条电话线，操作系统只能有一个窗口管理器，一台PC连一个键盘等等。

在单例模式的实现过程中，需要注意如下三点：

（1）单例类的构造函数为私有；

（2）提供一个自身的静态私有成员变量；

（3）提供一个公有的静态工厂方法。

单例模式的优点：

（1）提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它，并为设计及开发团队提供了共享的概念。

（2）由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。

（3）允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的

-3-

方法来获得指定个数的对象实例。

单例模式的缺点：

（1）由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。

（2）单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。

（3）滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致对象状态的丢失。

3.2结构型设计模式

结构型模式处理类或对象的组合，即描述类和对象之间怎样组织起来形成大的结构，从而实现新的功能。结构型类模式采用继承机制来组合类，如Adapter（适配器类）模式；结构型对象模式则描述了对象的组装方式，如Adapter（适配器对象）模式、Bridge（桥接）模式、Composite（组合）模式、Decorator（装饰）模式、Facade（外观）模式、Flyweight （享元）模式、Proxy（代理）模式。结构型模式中，Adapter是将一个类的接口转换成用户希望的另外一个接口；Bridge是将产品的抽象接口部分与具体实现部分分离；Composite是将对象组合成树型结构以表示“部分—整体”的层次结构；Decorator动态地给一个对象增加一些额外的职责；Facade是为子系统中的一组接口提供一个一致的界面；Flyweight使用共享技术支持大量细粒度对象；Proxy则是为其他对象提供一种代理以控制对这个对象的访问。

上述模式中，Adapter与Bridge的区别是：Bridge目的是将接口部分和实现部分分离，从而对它们可以较为容易也相对独立的加以改变，而Adapter则意味着要改变一个已有对象的接口；Decorator与Adapter的区别是：Decorator模式增强了对象的功能而又不改变对象的接口，但Adapter模式将给对象一个全新的接口；Proxy与Adapter的区别是：Proxy提供的是与其实体相同的接口，即在不改变接口的条件下，为另一个对象提供代理，而Adapter 为其所适配的对象提供了一个不同的接口。

例如：组合模式是将对象组合成树形结构以表示“部分—整体”的层次结构，Composite 使得客户对单个对象和复合对象的使用具有一致性。

使用场合：当需要描述的对象具有“递归组合”、且希望用户忽略基本对象与组合对象的区别时，可使用本模式。

组合模式结构图如图3-1所示。

-4-

图3-1 组合模式结构图

3.3行为型设计模式

行为型设计模式描述算法以及对象之间的任务（职责）分配，它所描述的不仅仅是类或对象的设计模式，还有它们之间的通讯模式。这些模式刻画了在运行时刻难以跟踪的复杂的控制流。行为型类模式使用继承机制在类间分派行为，如Template Method（模板方法）模式和Interpreter（解释器）模式；行为型对象模式使用对象复合而不是继承，它描述一组对象怎样协作完成单个对象所无法完成的任务，如Chain of Reponsibility（职责链）模式、Command（命令）模式、Iterator（迭代器）模式、Mediator（中介者）模式、Memento（备忘录）模式、Observer（观察者）模式、State（状态）模式、Strategy（策略）模式、Visitor （访问者）模式。

行为型模式中，Chain of Reponsibility模式是将处理某个请求的对象连成一条链，用户可以沿着这条链传递该请求，直到有一个对象处理它为止；Command模式是将一个请求封装成一个对象，从而可用不同的请求对客户进行参数化；Interpreter模式描述的是如何为某个语言定义文法，如何在该语言中表示一个句子以及如何解释这些句子；Iterator模式提供一种方法顺序访问一个聚合中的各个元素而又不暴露该对象的内部表示；Mediator是用一个中介对象来封装一系列复杂对象的交互，中介者使各对象不需要显示的相互引用；Memento 是在不破坏封装性的前提下，捕获一个对象的内部状态并在该对象之外保存这个状态，这样以后就可将该对象恢复到原先某一个状态；Observer是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知，并自动更新；State 模式是允许一个对象在其内部状态改变时改变它的行为；Strategy定义一系列的封装算法，把他们一个个封装起来，并使它们可以相互替换；Template Method是定义一个操作中的算法的构架，而将一些步骤延迟到子类中（即一次性实现一个算法的不变部分，并将可变的行为留给子类来实现）；Visitor模式是使在不改变各元素类的前提下定义作用于这些元素的新操作。

-5-

-6-

上述行为模式之间是相互补充的关系，例如Iterator 可以遍历一个聚合，而Visitor 可以对聚合的每一个元素进行一个新操作。行为型模式和其他类型的模式也能很好的协同工作，如一个使用Composite 模式的系统可以使用Iterator 进行遍历或用一个Visitor 对该复合的个别元素进行一些新操作。

例如：模板方法模式(Template Method Pattern)：一个操作中算法的骨架(the skeleton of an algorithm) ，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式。

3.4各种模式之间的关系

如上所述，创建型模式与对象的创建有关，结构型模式处理类和对象的组合，行为型模式描述算法以及对象之间的任务分配。因此所有模式之间都是通过类或对象的创建、组合或通讯发生联系。图3-2显示出各模式之间的协作关系。

图3-2 各种设计模式与对象之间的关系图

4 结束语

模式这一概念尽管很早就已经存在，并且其中的很多方法（模式）在实际的软件设计中已经使用，但真正系统地整理、分类以形成一种理论始于Erich Gamma的博士论文[Gam91，Gam92]的部分工作，这个时间并不很长，国内研究软件设计模式的时间则更短。在国外，设计模式研究工作进展很快，人们不断总结出新的模式，并且很多软件开发工具和环境增加了对他们的支持，有些研究机构还设想将设计模式用形式化表示以让机器自动生成代码，一些类库正在被开发以支持设计模式的实现（如JA V A在其标准类库中提供了这样一些支持），除此之外，他们还提出了软件体系结构模式（Architectural Patterns）、代码模式（Idioms，或coding patterns）以及分布式系统设计模式（Distribute Design patterns）、实时系统设计模式（Real-Time Design Patterns）等等，具体可参见文献[2]、[3]和[4]。本文描述了设计模式在设计可重用性面向对象软件中的重要性、各种软件设计模式的概念和它们之间的关系，以及如何选择和使用这些模式。通过阅读本文能对软件设计模式有一个初步的理解，但是要真正理解这些模式的目的、结构、模式参与者、参与者之间的协作以及使用这些模式的效果，还必须研究和参考参考文献[1]，该书对此作了详细的论述，同时必须将这些模式不断用于实践。此外，正如Erich Gamma所说的一样，这些模式并不是绝对的，在实践过程中，还必须不断总结发现和整理使用过的设计模式，并记录下来，以提出新的软件设计模式。

参考文献

[1]Erich Gamma，Richard Helm，Ralph Johnson. Design Patterns：Elements of Reusable Object -Oriented Software[M]，Addison-Wesley Publishing Company，1995.

[2] Douglas C.Schmidt，Michael Stal，Hans Rohnert. Pattern Oriented Software Architecture：Patterns for Concurrent and Networked Objects （POSA2）[M]，Published by Wiley &Sons，2000.

[3]Mark Grand，Patterns in Java V olume 1，V olume 2，Volume 3[M]，Published by John Wiley &Sons，September 1998.

[4] Jean -Marc Jezequel，Michel Train，Christine Mingins. Design Patterns and Contracts[ M]，Published by Addison Wesley，2000.

[5] 李英军，设计模式[M]，北京：机械工业出版社，2000.

[6] RogerS，Pressman. 软件工程—实践者的研究方法，北京：机械工业出版社，2002.

[7] Er1ehG，RiehardH，RalphJetal. 设计模式：可复用面向对象软件的基础，北京：机械工业出版社，2000.

[8] 甄雷，.NET与设计模式，北京：电子工业出版社，2005.

-7-