软件设计模式的选择与实现_邹娟 (1)

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

设计模式的种类日益增多，相对于于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 Patterns

ZOU 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 Engineering

2004年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

的考虑

从以上分析可以看出，职责链模式和命令模式都提供了为请求的发送者和接收者之间的解耦功能，但是两者的处理方式截然不同：职责链模式将多个对象连成一条链，请求在多个对象中传递，具体被谁处理请求，发送者无法知道而由运行时刻决定，此模式所支持的变化是系统中可以增加多个满足一个请求的对象。而命令模式把请求封装成一个对象，把请求操作的对象和执行操作的对象分离，它能支持的变化是可以很容易地增加一个新的对象来满足新的请求，而不会影响对已有请求的处理。

考虑实际系统客户端的情况，对于计划追踪系统，用户通常进行的操作是对计划信息的添加、删除、修改、查询等。由于计划追踪系统实属的模块，一个不确定的处理结果显然

ERP

是客户无法接受的，根据这一特点，职责链模式就无法满足。而对于命令模式很容易通过对请求的封装来完成所需的操作，同时也容易扩展，例如：如果需要根据某一条件对多个计划进行查询，只需增加一个具体的命令对象就能实现。另外，命令模式可以与合成模式结合使用合成宏命令，与备忘

(Composite)

录模式一起使用来完成命令模式所支持的撤销(Memento)(undo)和恢复功能。根据以上分析，可以确定使用命令模式来(redo)

实现系统“客户端”的功能。

设计模式的实现

2.3

选择好模式以后，重要的是如何将模式应用到系统中，主要是针对模式的各参与者角色及其相互协调关系进行研究。下面介绍命令模式在计划追踪系统中的实现。

命令模式结构

2.3.1

我们所选择的命令模式的结构如图所示。

1

图命令模式结构图

1

在命令模式中，抽象的类是最主要的对象，它

Command

定义了一个执行操作的公共接口，具体的类

Concrete-Command 是类的实现，并调用接收者相应的方法，定Command Receive

义了接收者对象与操作之间的关联，而接收者类才是一

Receive

个具体负责实施和实现请求的对象。客户端负责创建一

Client

—80—

个具体命令对象并设定它的接收者，调用者调用命令对

Invoker

象执行请求操作。

命令模式在系统中的实现

2.3.2

计划追踪系统是建立在基础上的应用系统，采用了

Web

技术。系统的客户端采用了和来发送和传递J2EE JSP SERVLET

客户的请求，服务端是系统的核心，在其中又使用了多层结构，最底层为层，实现对数据库的直DAO(Data Access Object)

接访问，里面主要封装了一些原子操作；业务逻辑集中于BO

包括调用的方法和商业对象自身的方(Business Object),DAO

法；代理对象是的代理，是“客户端”访问“服务(Proxy)BO

端”的唯一通道，担任着“客户端”命令模式的接收者角色。命令模式在系统中的设计结构图如图所示。

2

图系统设计结构

2

其中是命令模式中的调用者，接收页面传来xxx_servlet JSP

的请求，并调用命令对象的方法，而具体

EventHandler Execute 执行的操作由请求来决定，、等是

CreteHandler ModifyHandler

具体命令，完成用户具体的请求操作。由结构图可以看出要在

系统中增加一个新的命令会变得非常容易，无须对已有具体命

令类进行改变，从而增强了系统的可扩展性和可重用性。

总结

3

设计模式作为软件领域里的一个新兴的研究方向，虽然发

展时间不长，但是它给设计和开发带来了很多好处，因而成为

研究的焦点。通常情况下，了解模式本身并不困难，但是模式

的选择和使用往往成为模式发挥作用的绊脚石。本文所提出的

模式筛选方法是我们在进行模式选择过程中总结出来的经验，

这种方法过程比较简单，是一种行之有效的模式选择方法。使

用这种方法选择模式，进行系统重复设计的机会少，从而能缩

短项目设计开发的周期，这在我们的计划跟踪系统中得到了良

好的应用。当然这种方法仍然依赖于设计人员对模式的熟练程

度。

从长远来看，由于越来越多的模式被开发和总结出来，所

有依赖于人工判断的传统模式选择方法都可能成为模式使用的

障碍。近年来已经出现了对设计模式形式化描述方法的研究，

这些方法通过对设计模式进行形式化描述，为用户进行模式选

择提供比较准确的数据。同时模式的自动获取方法也已经提

出，这些模式选择方法将是模式选择的趋势。

参考文献

1 Gamma E, Helm R, Johnson R, et al. Desing Patterns: Elements of

Reuseable Object-oriented Software [M]. Addison Wesley , 1995

阎宏与模式北京：电子工业出版社

2 . Java. , 2002

邱仲潘译实用设计模式编程指南北京：电子工业出版社，

3 . J2EE. 2003

万剑怡，薛锦云使用规范匹配实现设计模式的自动获取小型

4 . .

微型计算机系统，2002, 23(3)

上接第页

(61)

采用基于权限模型的管理方法，引入用户组、用户、角色、对象权限等要素，进行统一用户认证管理。该模型示意图见图。

3

服务平台

5.2 Agent

服务平台负责多个在网络环境中的分布与注Agent Agent

册，进行的状态管理，如属性、活动、触发条件、休Agent

眠、结束条件。通过服务平台，使多个之间可以

Agent Agent

通信，相当于在之间建立一条以服务平台为中介的

Agent Agent

连接，使得个的交互次数从减少为次，大大N Agent N*(N-1)2N

减轻了系统通信的耗费。

业务构件库

5.3 Agent

基于结构的层体系结构，研制统一认证系统和系统B/S3

导航器，数据库连接与组件服务，进行用户层和

Agent Servlet 在业务逻辑设计。这些通过业务构件库JavaBean JavaBean

进行存储、管理和调度，实施对后台数据库的连接、操Agent

作和结果反馈，并将信息通过服务平台传给用户界面，

Agent

实现业务处理的功能。

业务构件分两类：即公共类和业务逻辑类。公JavaBean

共构件作为构建和业务系统开发的可继承构件，包括数据EIP

库的连接或是连接池等；业务逻辑构件是针对中小企业()bean 业务逻辑设计，其中又分为对各种业务逻辑的实体和管

bean

理。其中实体主要是根据具体的业务逻辑构造相关的bean bean

实体模型，管理主要是对具体业务逻辑的管理，包括相

bean

关业务信息的增加、删除、修改、查询等。

结束语

6

在分析门户技术和技术基础上，研究了基于的

Agent Agent

中小企业构架，设计多，并对实现与企业业务逻辑EIP Agent

一体化方案进行了实践。本研究作为“十五”“”项目的

863

内容之一，单项技术和方法已经得到应用，初步形成了相

EIP

关产品部件，正通过中科院与地方合作的中小企业进行验

证。

参考文献

，

1 Crowe M Kydd S. Agents and Suggestions in a Web-based Dynamic

，，

Workflow Model.Automation in Construction 2001(10): 639-643

2 FIPA.FIPA ACL Message Structure Specification.https://www.360docs.net/doc/4d10569403.html,/

，

specs/fipa00061/2001

3 Botha R,Elof J H P.Access Control in Documentcentric Workflow

——

Systems An Agent-based https://www.360docs.net/doc/4d10569403.html,puters & Security,2001, 20(6): 525-532

4 http://www.idi.ntnu.no/~alfw/publications/sea2000-wf-agent.pdf

徐家俊万涛管理信息化热点问题讨论之五：推开“门户”看个5 ,.

究竟.https://www.360docs.net/doc/4d10569403.html,

—81—

CreateHandler Proxy

Execute()ModifyHandler

Proxy

Execute()

DeleteHandler

Proxy

Execute()

create()

modify()

delete()

find()

FindHandler

Proxy

Execute()

xxx_servlet

E

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆