软件业的发展不仅要求软件有更高的生产率和可靠性，而且对软件的可重用性和可维护性也提出了更高的要求。

设计模式以文档的形式把面向对象的软件设计经验记录下来，并予以系统的命名、解释和评价，使开发人员在进行系统的设计与开发时，可以使用别人的成功经验而不必为普通的、重复的问题重新设计解决方案，使设计者更容易理解其设计思路，能为自己的问题找到更合适的解决办法，帮助设计者更快更好地完成系统设计。

设计模式的种类日益增多，相对于于Gang of Four (GoF)年提出的种通用的设计模式，设计模式的数量已经大大199523增加了。

要从如此多的模式中选择适合自己系统的模式并非易事，选择正确、恰当的模式成为人们使用模式的瓶颈，尤其是对于模式不够熟悉的用户。

因此，寻找一种简易有效的模式选择方法对于使用模式的用户来说非常重要。

设计模式概述1 设计模式是针对面向对象系统中重复出现的问题而提出来的。

有经验的面向对象专家在解决问题时，通常先考虑以前解决过的相似问题，并重用其解法的精华来解决问题，这个不断被引用的解法就是通常说的设计模式。

设计模式的历程并不长，但它已日渐成为软件工程研究的重要方向，是软件学科中的一个新领域。

模式最早出自建筑大师的关于城市规划和建筑设计的著作中。

Christopher Alexander 目前，设计模式还没有统一的定义，大多数都采用建筑大师对模式的定义，他曾在其著作中指出：Christopher Alexander “每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。

这样，你就能一次又一次地使用该方案而不必做重复劳动。

”该定义的核心在于提供一个相关问题的解决方案，使人们避免了不必要的重复劳动。

在软件设计中，也会有不断重复出现的问题，因此该思想同样适用于软件行业。

可以简单地认为，设计模式就是解决某个特定的面向对象软件问题的特定方法。

每个设计模式都有统一的描述，以利于其他人使用，实现资源共享。

模式的描述形式通常分为两类：一类是经典的自然语言结合框图的非形式化描述形式，一类是形式化描述。

OO 目前通常采用的非形式化描述形式，包括标题和详述。

一GoF 个模式描述通常要求包括如下信息：模式名称：每个模式都有唯一的名称，用于简述模式的本质。

(1)人们通过模式名称来鉴别模式；意图：描述设计模式解决什么样的特定设计问题及其基本原(2) 理；解决方案：这是设计模式的核心。

描述模式在自己出现的情境(3)中怎样提供一个解决方案；参与者：即模式包括的实体，指模式中的类或对象及其各自的(4)职责；协作：模式的参与者之间如何协调完成他们的职责；(5)效果：使用模式的优点和存在的不足；(6)实现：指怎样实现模式，是模式的具体表现形式，实现同一模(7)式的方法通常会有很多种；相关模式：与模式紧密相关的其他模式，它们可能在很大程度(8)上有相似之处，或者可以相互补充。

模式是良好设计方案的总结，然而在设计中也会发现一些不好的设计方法，这就是反模式。

反模式表示的是不可行方案或用到错误情境中的方案。

尽快表示错误有利于减少项目的风险，因此了解反模式对于每个设计人员也非常重要，它有助于防止在自己的设计中犯同样的错误。

设计模式的选择与实现2 设计模式选择方法2.1 使用设计模式能给设计人员带来很多好处，而要得到这样的好处，需要根据实际情况，进行正确的模式选择。

选择模式的方法很多，特别是随着对设计模式研究的广泛开展，越来越多的模式被发现，人们也开始寻找自动获取模式的方法，但还不成熟。

在目前的实际工作当中，人们仍然采用传统的模式选择方法，主要凭借对设计模式功能的理解和自身的设计经验。

这要求设计人员对所有设计模式都有较深的理解和掌握。

然软件设计模式的选择与实现邹娟，田玉敏（西安电子科技大学计算机外部设备研究所，西安）710071摘要： 设计模式是人们在实践过程中总结出来的成功设计范例，它的正确选择和使用是发挥模式作用的关键。

该文从模式的基本概念入手，详细讨论了选择设计模式的正确方法，并结合实例讨论了模式选择方法在计划追踪系统中的具体实现。

关键词：设计模式；模式选择；计划追踪系统Selection and Realization for Software Design PatternsZOU Juan, TIAN Yumin( Research Institute of Peripherals, Xidian University, Xi'an 710071)【】Abstract Design patterns are successful design examples which people summarized in practice. How to correctly select and use these patterns is important to bring them into play. This paper, beginning with basic conception of mode, discusses in detail how to correctly select method to design pattern . It also discusses the implementation of pattern selecting in the plan-track system as an example. 【】Key words Design pattern; Pattern selecting; Plan-track system第30卷　第10期Vol.30 № 10计　算　机　工　程Computer Engineering2004年5月May 2004・ 软件技术与数据库・中图分类号：TP 311文章编号：1000—3428(2004)10 —0079—03文献标识码：A而，对于模式选择方法的介绍，大多是基于单个方法的，并没有对方法间的联系加以阐述，容易导致人们孤立地看待问题，不便于使用。

我们通过对已有的模式选择方法加以总结、归纳、简化并把它们联系起来，发现在选择模式时基本可以遵循以下的步骤和原则：理解问题需求：需求是模式选择的基础，通过对需求的分析可(1)以找到多个模式，形成模式组；研究组内模式：需求分析得出的组内模式有一些共性，但是每(2)种模式都有其特殊的意图、使用动机和使用条件，因此需要对组内模式进行研究；考虑设计模式如何解决设计问题：在此过程中，主要考虑设计(3)模式在设计中所支持的可变化因素，即确定改变什么而不需重新设计，根据这一点可以找到所需的设计模式。

此外考虑与其相关的设计模式。

根据以上步的筛选就能选出符合需求的设计模式。

通过3在计划追踪系统的设计开发中的应用，说明这是一个行之有效的模式选择方法。

设计模式选择方法的使用2.2任意一个需求，都有可能牵涉到多个特定的问题领域，而每一种设计模式都有其特定的意图和目的，因此一个实际的应用通常需要使用多种模式。

计划追踪系统是系统的一个子ERP系统，主要给用户提供计划信息的维护，对计划的执行情况进行跟踪和对计划进行考核等功能。

为了提高系统的可扩展性和可维护性，我们在系统中使用了单例模式、(Singleton)工厂方法、代理模式、(Factory Method)(Proxy)DAO(Data、命令模式等大量的设计模式，每种Access Object)(Command)设计模式都通过相关的筛选而获得。

下面以选择命令模式为例来说明如何根据实际问题选择正确的模式。

理解问题需求2.2.1通常，一个具体应用按大的层次来分，可以分为“客户端”和“服务端”两大层。

在一个系统中，“客户端”的作用是接收客户的请求，并把请求传给“服务端”进行处理。

实际上这是一个事件驱动模型，客户的每个请求都是一个事件，通过“客户端”把请求传入“服务端”，至于具体怎么传递，应该是一个动态的过程，客户无须知晓。

据经验分析，目前用于“客户端”处理请求的主要模式是职责链模式(Chain of 和命令模式。

这样，就从众多的模式Responsibility)(Command)中找出了可能符合系统需求的模式组。

在这里组内只有这两种模式。

组内模式研究2.2.2从模式的分类角度看，职责链模式和命令模式都属于对象的行为模式，它们之间有一些共性：它们都提供请求的发送(1)者和接收者之间解耦合的功能；二者都可以在编译时刻或运(2)行时刻改变相应请求。

但是二者的意图即所要解决的设计问(题和使用条件各不相同：)从意图来讲，职责链模式解决的是使多个对象都有机会处理请(1)求，从而避免请求的发送者和接收者之间的耦合关系；而命令模式是将一个请求封装成一个对象，从而可以用不同的请求对客户进行参数化，对请求排列或记录请求日志以及支持可撤销的操作。

从使用条件来讲，职责链模式通常适用于以下条件：多个对(2)1)象可以处理一个请求，哪个对象处理该请求由运行时刻自动决定；2)在不明确指定接受者的情况下，向多个对象中的一个提交一个请求；可处理一个请求的对象集合被动态指定。

而命令模式通常在以下条3)件使用：使用命令模式作为“回呼”面向对象系统中的替代；在1)2)不同的时刻制定、排列和执行请求；支持取消操作；支持修改日3)4)志；用构建在原语操作上的高层操作构造一个子系统。

5)同时两种模式各有其优缺点：在职责链模式中，由于有多个对象处理同一个请求，每个对象仅需要一个后继对象的引用而不是所有候选者的引用，从而减少了对象的相互连接，具体处理请求的对象由运行时刻或根据上下文来决定，这样处理增加了系统处理的灵活性，但是每个请求发出后，需在一批已提供的处理者中逐个挑选出合适的处理者进行处理，这样大大降低了系统的性能。

而命令模式通过把请求封装成一个对象，请求的发送者对象是对命令对象进行引用而不是对接收者对象的引用，请求方不必知道接收方的接口，也不必知道接收方的具体实现，从而减少了请求发送者和接收者对象之间的耦合，但是在命令模式中由于对每个具体请求都要进行封装，可能会导致系统中有很多的具体命令类。

对模式解决涉及问题2.2.3的考虑从以上分析可以看出，职责链模式和命令模式都提供了为请求的发送者和接收者之间的解耦功能，但是两者的处理方式截然不同：职责链模式将多个对象连成一条链，请求在多个对象中传递，具体被谁处理请求，发送者无法知道而由运行时刻决定，此模式所支持的变化是系统中可以增加多个满足一个请求的对象。

而命令模式把请求封装成一个对象，把请求操作的对象和执行操作的对象分离，它能支持的变化是可以很容易地增加一个新的对象来满足新的请求，而不会影响对已有请求的处理。