[软件工程] 面向对象设计

面向对象设计

设计就是将分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。
从面向对象分析到面向对象设计(OOD)，是用面向对象观点建立求解域模型、逐渐扩充模型的过程。
面向对象分析和设计在软件开发过程中的界限是模糊的，分析和设计活动是一个多次反复迭代的过程。
结构化方法的设计分为总体设计和详细设计，面向对象设计可细分为系统设计和对象设计(本书不区分两者)。
面向对象开发过程的应用生存期模型

一、 面向对象设计的准则

结构化软件设计基本原理仍然成立：
对于面向对象方法的新特点，增加了下列的面向对象设计准则。

（一） 模块化

因为对象就是模块，所以面向对象软件开发模式完全符合系统的模块化设计原理。
对象模块将数据结构和操作紧密地结合在一起。

（二） 抽象

类是一种抽象数据类型：
通过类提供的公共接口及合法操作符，对类实例中包含的数据进行操作。使用者无须知道这些操作符的实现算法和类中数据元素的具体表示方法，可以使用类中定义的数据。

（三） 信息隐藏

在面向对象方法中，通过对象的封装性实现了信息隐藏：
类结构分离了接口与实现，用户来说，类属性的表示方法和类操作的实现算法都应设计成是隐藏的，从而支持信息隐藏。

（四） 弱耦合

在面向对象方法中，对象是最基本的模块，耦合是指各对象之间相互关联的紧密程度。
对象不可能是完全孤立的，当两个对象必须相互联系相互依赖时，应该通过类的协议(即公共接
口)实现耦合，而不应该依赖于类的具体实现细节。

对象之间的耦合可分为两大类：

(1) 交互耦合

如果对象之间的耦合通过消息连接来实现，则这种耦合就是交互耦合。
为使交互耦合尽可能松散，应该遵守下述准则：
①尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度。
②减少对象发送(或接收)的消息数。

(2) 继承耦合

继承是一般化类与特殊类之间耦合的一种形式。
与交互耦合相反，应该提高继承耦合程度。
从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块。因此，它们彼此之间应该结合得越紧密越好。
为获得紧密的继承耦合，在设计时应该使特殊类尽量多继承并使用其一般化类的属性和服务。

（五）强内聚

内聚衡量一个模块内各个元素彼此结合的紧密程度。
在设计时应该力求做到高内聚。
在面向对象设计中存在下述3种内聚：
（1） 服务内聚
一个服务应该完成一个且仅完成一个功能。
（2） 类内聚
设计类的原则：一个类应只有一个用途，它的属性和服务应该是高内聚的。
（3）一般—特殊内聚
类对象的关系中，一般与特殊的关系称为泛化
（Generalization）与特化（Specialization）联系。
设计出的一般-特殊结构，应该符合多数人的概念，应该是对相应的领域知识的正确抽取。
紧密的继承耦合与高度的一般-特殊内聚是一致的。

（六）可重用

软件重用基本上从设计阶段开始。
重用有两方面的含义：
一是尽量使用已有的类(包括开发环境提供的类库，及以往开发类似系统时创建的类)；
二是如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性。

二、启发规则

启发规则能提高面向对象设计的质量。

（一） 设计结果应该清晰易懂

使设计结果清晰、易读、易懂，是提高软件可维护性和可重用性的重要措施。
保证设计结果清晰易懂的主要因素如下：

1.用词一致

应该使名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字。不同类中相似服务的名字应该相同。

2.使用已有的协议

如果开发同一软件的其他设计人员已经建立了类的协议，或者在所使用的类库中已有相应的协议，则应该使用这些已有的协议。

3.减少消息模式的数目有标准的消息协议，应该遵守这些协议。

自己建立消息协议，则应尽量减少消息模式的数目，尽可能使消息具有一致的模式，利于理解。

4.避免模糊的定义

一个类的用途应该是有限的，而且应该从类名可以较容易地推想出它的用途。

（二） 一般-特殊结构的深度应适当应该使类等级中包含的层次数适当。

在一个中等规模(大约包含100个类)的系统中，类等级层次数应保持为7±2。
不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般-特殊结构与领域知识或常识保持一致。

（三）设计简单的类

应尽量设计小而简单的类，以便于开发和管理。当类很大的时候，要记住它的所有服务是非常困难的。
经验表明，如果一个类的定义不超过一页纸(或两屏)，则使用这个类是比较容易的。为使类保持简单，应该注意以下几点。

1.避免包含过多的属性

属性过多表明这个类过分复杂了，它所完成的功能可能太多了。

2. 有明确的定义

为了使类的定义明确，分配给每个类的任务应该简单，最好能用一两个简单语句描述它的任务。

3. 尽量简化对象之间的合作关系

多个对象合做一件事，类的简明性和清晰性受到影响。

4.不要提供太多服务一个类提供的公共服务不超过7个。

当遵循上述原则设计出大量较小的类时，通过划分“主题”减小复杂性。

三、软件重用

（一） 概述

1. 重用

重用也叫复用，软件重用可分为以下3个层次：
(1) 知识重用(例如，软件工程知识的重用)。
(2) 方法和标准的重用(例如，面向对象方法或国家制定的软件开发规范的重用)。
(3) 软件成分的重用。
前两个重用层次属于知识工程研究的范畴，本节仅讨论软件成分重用问题。

2.3个级别：

软件成分的重用级别软件成分的重用可以进一步划分成以下3个级别：

(1) 代码重用

代码重用可采用下列几种形式中的任何一种：源代码剪贴
缺点——复制或修改原有代码时可能出错，存在严重的配置管理问题，人们几乎无法跟踪原始代码块多次修改重用的过程。利用继承机制重用类库中的类时，无须修改已有的代码，就可以扩充或具体化在库中找出的类，因此，基本上不存在配置管理问题。

(2) 设计结果重用

设计结果重用——重用某个软件系统的设计模型(即求解域模型)。
这个级别的重用有助于把一个应用系统移植到完全不同的软硬件平台上。

(3) 分析结果重用

重用某个系统的分析模型——特别适用于用户需求未改变，但系统体系结构发生了根本变化的场合。

3. 典型的可重用软件成分

可能被重用的软件成分主要有以下10种：
（1）项目计划
（2）成本估计
（3）体系结构
（4）需求模型和规格说明
（5）设计
（6）源代码
（7）用户文档和技术文档
（8）用户界面
（9）数据
（10）测试用例
面向对象中的“类”是比较理想的可重用软构件（类构件）。

（二） 类构件

类构件有3种重用方式：
实例重用
继承重用
多态重用

1. 可重用软构件应具备的特点

(1) 模块独立性强

(2) 具有高度可塑性

提供为适应特定需求而扩充或修改已有构件的机制，且这种机制用起来简单方便。
提供为适应特定需求而扩充或修改已有构件的机制，且这种机制用起来简单方便。0

(3)接口清晰、简明、可靠

软构件应提供清晰、简明、可靠的对外接口，而且还应有详尽的文档说明，以方便用户使用。

2. 类构件的重用方式

(1) 实例重用

形式1：使用适当的构造函数，按需创建类的实例。然后发送适当的消息，启动相应的服务，完成需要完成的工作。
形式2：由几个简单的对象作为类的成员，创建出一个较复杂的类。

(2) 继承重用

当已有类构件不能通过实例重用满足系统需求时，继承重用提供了一种手段，安全地修改已有类构件达到重用的目的。
这样做有下述两个好处：
A) 子类继承父类,降低了每个类构件的接口复杂度、提高每个子类的可理解性，而且为软件开发人员提供了更多可重用的类构件。
B) 为多态重用奠定了良好基础。

(3) 多态重用

由于基类与派生类的许多对外接口是相同的，多态性使对象的对外接口更加一般化——降低了消息连接的复杂程度，提供了一种简便可靠的软构件组合机制。
系统运行时，根据接收消息的对象类型，由多态性机制启动正确的方法，去响应一个一般化的消息，从而简化了消息界面和软构件连接过程。

（三） 软件重用的效益

1. 质量

随着每一次重用，构件的质量也会随之改善。
没有缺陷的软件才能重用。

2. 生产率

重用使得创建计划、模型、文档、代码和数据所需花费的时间将减少，生产率得到了提高.
30%~50%的重用大约可以导致生产率提高25% ~40%。

3. 成本

软件重用净成本节省估算：C=Cs-Cr-Cd
Cs~没有重用时所需要的成本；
Cr~与重用相关联的成本；
Cd~交付给客户的软件的实际成本。

四、 系统分解

系统分解成若干个小的部分，然后再分别设计每个部分——降低设计的难度，有利于分工协作，也有利于维护人员对系统理解和维护。
子系统的数目应该与系统规模匹配，应设计简单、明确的接口。
在划分和设计子系统时，应该尽量减少子系统彼此间的依赖性。
面向对象设计模型同分析模型相同，也由主题层、类与对象层、结构层、属性层、服务层5个层次组成。

（一） 子系统之间的两种交互方式

在软件系统中，子系统之间的交互有两种可能的方式，分别是客户-供应商(Client-supplier)关系和平等伙伴(peer-to-peer)关系。

1. 客户-供应商关系

作为“客户”的子系统调用作为“供应商”的子系统，后者完成某些服务工作并返回结果。
使用这种交互方案，作为客户的子系统必须了解作为供应商的子系统的接口，然而后者却无须了解前者的接口，因为任何交互行为都是由前者驱动的。

2. 平等伙伴关系

每个子系统都可能调用其他子系统，因此，每个子系统都必须了解其他子系统的接口。
同客户-供应商方案比较，各子系统之间的交互更复杂，而且还可能存在通信环路，从而使系统难于理解，容易发生不易察觉的设计错误。
总的说来，单向交互比双向交互更容易理解，也更容易设计和修改——应该尽量使用客户-供应商关系。

（二）组织系统的两种方案

把子系统组织成完整的系统时，有水平的层次组织和垂直的块组织两种方案可供选择。

1.层次组织

把软件系统组织成一个层次系统，每层是一个子系统。上层在下层的基础上建立，下层为实现上层功能而提供必要的服务。
同一层内所包含的对象，彼此间相互独立; 不同层次上的对象，彼此间往往有关联。
上、下层之间明显存在客户-供应商关系。低层子系统提供服务，相当于供应商，上层子系统使用下层提供的服务，相当于客户。

2. 块状组织

软件系统垂直地分解成若干个相对独立的、弱耦合的子系统，一个子系统相当于一块，每块提供一种类型的服务。
利用层次和块的各种可能的组合，可以成功地由多个子系统组成一个完整的软件系统。
当混合使用层次结构和块状结构时，同一层次可以由若干块组成，而同一块也可以分为若干层。
例如，图表示一个应用系统的组织结构，这个应用系统采用了层次与块状的混合结构。

（三）设计系统的拓扑结构

用子系统组成完整的系统时，设计者应该采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量。
典型的拓扑结构有管道形、树形、星形等。

五、 设计问题域子系统

问题域：直接负责实现客户需求的子系统。
面向对象方法在分析与设计之间并没有明确的分界线，对于问题域子系统来说，情况更是如此。
但是分析工作可以而且应该与具体实现无关，设计工作则在很大程度上受具体实现环境的约束。
（使用的编程语言、可用的软构件库(主要是类
库)、编程经验等）。
 将结构化分析模型转换为软件设计
 
面向对象的分析与设计模型转换关系

面向对象分析——问题域精确模型，为设计问题域子系统奠定了良好的基础，建立了完整的框架。
尽量保持面向对象分析所建立的问题域结构。
通常，面向对象设计仅需从实现角度对问题域模型做一些补充或修改：
增添、合并或分解类与对象、属性及服务，调整继承关系等等。
当问题域子系统过分复杂庞大时，应该把它进一步分解成若干个更小的子系统。

下面介绍，在面向对象设计过程中，可能对面
向对象分析所得出的问题域模型做的补充或修改。

（一）调整需求两种情况修改

一是用户需求或外部环境发生了变化；
二是分析员对问题域理解不透彻或缺乏领域专家帮助，以致面向对象分析模型不能完整、准确地反映用户的真实需求。

（二）重用已有的类

重用已有类的典型过程如下：
　　(1) 选择已有类作为候选类，标出候选类中对本问题无用的属性和服务，尽量重用那些能使无用的属性和服务降到最低程度的类。
　　(2) 通过被重用的已有类→派生出问题域类。
　　(3) 问题域类中从已有类继承来的属性和服务，不用定义它们（在问题域类内）。
　　(4) 修改与问题域类相关的关联，必要时改为与被重用的已有类相关的关联。

（三） 把问题域类组合在一起设计中，通常引入根类而把问题域类组合起来。

在没有更先进的组合机制可用时，才采用引入根类的组合方法。

（四） 增添一般化类以建立协议

在设计中，一些具体类需要有一个公共的协议，即都需要定义一组类似的服务。
在这种情况下可以引入一个附加类(例如，根类)，以便建立这个协议(即命名公共服务集合，这些服务在具体类中仔细定义)。

（五） 调整继承层次

使用多重继承机制时，应该避免出现属性及服务的命名冲突。
　　下面通过例子说明避免命名冲突的方法。
　　图11.4是一种多重继承模式的例子，这种模式可以称为窄菱形模式。使用这种模式时出现属性及服务命名冲突的可能性比较大。

（六） ATM系统实例

图描绘了上章给出的ATM系统的问题域子系统的结构。
　　由于在面向对象分析过程中已经对ATM系统做了相当仔细的分析，而且假设所使用的实现环境能完全支持面向对象分析模型的实现，因此，在面向对象设计阶段无须对已有的问题域模型作实质性的修改或扩充。

　　　　　　　　　　　　　　图11.7 ATM系统问题域子系统的结构

六、 设计人机交互子系统

在面向对象分析中，对用户界面需求做了初步分析，在设计中，则应该对系统的人机交互子系统进行详细设计，以确定人机交互的细节：指定窗口和报表的形式、设计命令层次等项内容。
设计人机交互子系统的策略简介如下：

（一） 分类用户

通常从下列几个不同角度进行分类：按技能水平分类(新手、初级、中级、高级)。
　　按职务分类(总经理、经理、职员)。
　　按所属集团分类(职员、顾客)。

（二） 描述用户仔细了解将使用系统的每类用户的情况

用户类型；使用系统欲达到的目的；特征(年龄、性别、受教育程度、限制因素等)；关键的成功因素(需求、爱好、习惯等)；技能水平；完成本职工作的脚本。

（三）设计命令层次

设计命令层次的工作通常包含以下几项内容。

１．研究现有的人机交互含义和准则

设计图形用户界面时，应该保持与普通Windo ws应用程序界面相一致，并遵守广大用户习惯的约定，这样才会被用户接受和喜爱。

２．确定初始的命令层次

所谓命令层次，实质上是用过程抽象机制组织起来的、可供选用的服务的表示形式。设计命令层次时，通常先从对服务的过程抽象着手，然后再进一步修改它们，以适合具体应用环境的需要。

３． 精化命令层次

为进一步修改完善初始的命令层次，应该考虑下列一些因素：
次序：仔细选择每个服务的名字，并在命令层的每一部分内把服务排好次序。
整体-部分关系：寻找在这些服务中存在的整体部分模式，这样做有助于在命令层中分组组织服务。
宽度和深度：由于人的短期记忆能力有限，命令层次的宽度和深度都不应该过大。
操作步骤：用尽量少的单击、拖动和击键组合来表达命令，且应为高级用户提供简捷的操作。

4. 设计人机交互类

人机交互类与所使用的操作系统及编程语言密切相关。例如，在Windows环境下运行的Visual C++语言提供了MFC类库，设计人机交互类时，往往仅需从MFC类库中选出一些适用的类，然后从这些类派生出符合自己需要的类就可以了。
　　任务：通常指软件功能需求所载明的软件应完成的功能。
　　任务管理器：用于协调各个功能的调度和执行。
分析阶段（OOA）未涉及系统的具体实现细节，未引入任务管理部件。

设计阶段（OOD ）引入任务管理部件原因：
　　①多用户、多任务系统上开发应用程序的需要；
　　②通过任务管理部件协调各个子系统之间的通信和协同；
　　
设计工作的一项重要内容就是，确定哪些是必须同时动作的对象（并发），哪些是相互排斥的对象
（非并发），然后进一步设计任务管理子系统。

七、 设计任务管理子系统

任务：通常指软件功能需求所载明的软件应完成的功能。
　　任务管理器：用于协调各个功能的调度和执行。
分析阶段（OOA）未涉及系统的具体实现细节，未引入任务管理部件。
设计阶段（OOD ）引入任务管理部件原因：
①多用户、多任务系统上开发应用程序的需要；
②通过任务管理部件协调各个子系统之间的通信和协同；
设计工作的一项重要内容就是，确定哪些是必须同时动作的对象（并发），哪些是相互排斥的对象（非并发），然后进一步设计任务管理子系统。
与任务管理(控制驱动)部分设计有关的技术 ：

（一）分析并发性

分析中的动态模型（状态图）是分析并发性的主要依据。
　　并发：两个对象同时接受事件、彼此间不存在交互。
　　可将若干个非并发的对象归并到一条控制线（是一条遍及状态图集合的路径）上，在这条控制线上每次只有一个对象是活动的。
　　在计算机系统中用任务(task)实现控制线，任务是进程(process)的别名。通常把多个任务的并发执行称为多任务。
　　对于某些应用系统来说，通过划分任务，可以简化系统的设计及编码工作。

（二） 设计任务管理子系统

常见的任务有：

• 事件驱动型任务
• 时钟驱动型任务
• 优先任务
• 关键任务
• 协调任务等。

设计任务管理子系统，包括确定各类任务并把任务分配给适当的硬件或软件去执行。

１．确定事件驱动型任务

某些任务是由事件驱动的，这类任务可能主要完成通信工作。
事件通常是表明某些数据到达的信号。

２．确定时钟驱动型任务

某些任务每隔一定时间间隔就被触发以执行某些处理，例如，某些设备需要周期性地获得数据；某些人机接口、子系统、任务、处理器或其他系统也可能需要周期性地通信。在这些场合往往需要使用时钟驱动型任务。

３．确定优先任务

优先任务可以满足高优先级或低优先级的处理需求：
　　高优先级：某些服务具有很高的优先级，为了在严格限定的时间内完成这种服务，可能需要把这类服务分离成独立的任务。
　　低优先级：与高优先级相反，有些服务是低优先级的，属于低优先级处理。设计时可能用额外的任务把这样的处理分离出来。

４．确定关键任务

关键任务是有关系统成功或失败的关键处理，这类处理通常都有严格的可靠性要求。在设计过程中可能用额外的任务把这样的关键处理分离出来，以满足高可靠性处理的要求。

５．确定协调任务

当系统中存在3个以上任务时，就应该增加一个任务，用它作为协调任务。引入协调任务会增加系统的总开销(增加从一个任务到另一个任务的转换时间)，但是引入协调任务有助于把不同任务之间的协调控制封装起来。

６．尽量减少任务数

必须仔细分析和选择每个确实需要的任务。应该使系统中包含的任务数尽量少。
过多的任务加大了设计工作的技术复杂度，并使系统变得不易理解，从而也加大了系统维护的难度。

７．确定资源需求

使用多处理器，主要是为了满足高性能的需求。
设计者必须通过计算系统载荷(即每秒处理的业务数及处理一个业务所花费的时间)，来估算所需要的CPU(或其他固件)的处理能力。

八、 设计数据管理子系统

数据管理子系统是系统存储或检索对象的基本设施或组织形式，它建立在某种数据存储管理系统之上，并且隔离了数据存储管理模式(文件、关系数据库或面向对象数据库)的影响。

（一） 选择数据存储管理模式

不同的数据存储管理模式有不同的特点，适用范围也不相同，应根据应用系统的特点选择适用的数据存储管理模式。

1. 文件管理系统

文件管理系统是操作系统的一个组成部分，使用它长期保存数据具有成本低和简单等特点。
　　但是，文件操作的级别低，为提供适当的抽象级别还必须编写额外的代码（例如：考试系统的答案，使用文本文件类型）。
　　此外，不同操作系统的文件管理系统往往有明显差异。

2. 关系数据库管理系统

关系数据库管理系统的理论基础是关系代数，它不仅理论基础坚实而且有下列一些主要优点：
　　(1) 提供了各种最基本的数据管理功能(例如，中断恢复，多用户共享，多应用共享，完整性，事务支持等)。
　　(2) 为多种应用提供了一致的接口。
　　(3) 标准化的语言(大多数商品化关系数据库管理系统都使用SQL语言)。

关系数据库管理系统通常都相当复杂，缺点：
　　(1) 运行开销大：即使只完成简单的事务(例如，只修改表中的一行)，也需要较长的时间。
　　(2) 不能满足高级应用的需求：关系数据库管理系统是为商务应用服务的，商务应用中数据量虽大但数据结构却比较简单。关系数据库管理系统很难用在数据类型丰富或操作不标准的应用中。
　　(3) 与程序设计语言的连接不自然：SQL语言支持面向集合的操作，是一种非过程性语言；然而大多数程序设计语言本质上却是过程性的，每次只能处理一个记录。

3. 面向对象数据库管理系统

面向对象数据库管理系统是一种新技术，主要有两种设计途径：
　　➢扩展的关系数据库管理系统
　　➢扩展的面向对象程序设计语言
　　　(1) 扩展的关系数据库管理系统是在关系数据库的基础上，增加了抽象数据类型和继承机制，增加了创建及管理类和对象的通用服务。
　　　(2) 扩展的面向对象程序设计语言扩充了面向对象程序设计语言的语法和功能，增加了在数据库中存储和管理对象的机制。

（二）设计数据管理子系统

设计数据管理子系统，既需要设计数据格式又需要设计相应的服务。

1. 设计数据格式

设计数据格式的方法与所使用的数据存储管理模式密切相关，分别介绍如下：

(1) 文件系统

• 定义第一范式表：列出每个类的属性表；把属性表规范成第一范式，从而得到第一范式表的定义。
• 为每个第一范式表定义一个文件；测量性能和需要的存储容量；修改原设计的第一范式以满足性能和存储需求；必要时把泛化结构的属性压缩在单个文件中，以减少文件数量。
• 必要时把某些属性组合在一起，并用某种编码值表示这些属性，而不再分别使用独立的域表示每个属性。这样做可以减少所需要的存储空间，但是增加了处理时间。

(2) 关系数据库管理系统

• 定义第三范式表：列出每个类的属性表；把属性表规范成第三范式，从而得出第三范式表的定义。
• 为每个第三范式表定义一个数据库表。
• 测量性能和需要的存储容量。
• 修改先前设计的第三范式，以满足性能和存储需求。

(3) 面向对象数据库管理系统

• 扩展的关系数据库途径：使用与关系数据库管理系统相同的方法。
• 扩展的面向对象程序设计语言途径：不需要规范化属性的步骤，因为数据库管理系统本身具有把对象值映射成存储值的功能。

2. 设计相应的服务

某个类的对象需要存储，则在这个类中增加一个属性和服务→用于完成存储对象自身的工作。
　　此时增加的属性和服务作为“隐含”的属性和服务，设计模型中的属性和服务层中不必显式地表示它们，仅需在关于类与对象的文档中描述它们。

九、设计类中的服务

（一）设计类中应有的服务

综合考虑对象模型、动态模型和功能模型是正确确定类中应有的服务的前提。
　　对象模型通常在每个类中只列出很少几个最核心的服务。设计者必须把动态模型中对象的行为以及功能模型中的数据处理，转换成由适当的类所提供的服务。
　　状态图描绘了一类对象的生命周期，状态转换是执行对象服务的结果。
　　功能模型指明了系统必须提供的服务。状态图中状态转换所触发的动作，在功能模型中有时可能扩展成一张数据流图。
　　数据流图中的某些处理可能与对象提供的服务相对应，下列规则有助于确定操作的目标对象：
　　（1） 如果某个处理的功能是从输入流中抽取一个值，则该输入流就是目标对象（处理是针对输入流的，例如：学生成绩-计算总成绩）。
　　（2） 如果一个处理有相同类型的输入流和输出流，而且大部分输出值是输入流的更新版本，那么输入/输出是目标（原工资清单-调工资-现工资清单）。
　　（3） 如果一个处理由几个输入流得出输出值，那么该操作是一个输出类上的类操作（构造函数）。
　　（4） 如果一个处理的输入来自或输出到达一个数据存储或施动者，那么数据存储或施动者是处理的一个目标。

（二）设计实现服务的方法

设计实现服务的方法，还应需完成如下几项工作。
　1. 设计实现服务的算法设计实现服务的算法时，应考虑下列几个因素：
　　　(1) 算法复杂度
　　　　　通常选用复杂度较低(即效率较高)的算法，但也
　　　　　不要过分追求高效率，应以能满足用户需求为准。
　　　(2) 容易理解与容易实现
　　　(3) 易修改
　2. 选择数据结构
　　　设计过程中需要选择能够方便、有效地实现算法的数据结构。
　3. 定义内部类和内部操作
　　　在设计过程中，可能需要增添在需求陈述中没有提到的类，主要用来存放在执行算法过程中所得出的某些中间结果-内部类。
　　　在高层操作分解中可能会发现新的低层操作，这些低层操作必须在对象设计阶段定义，因为它们大多数都外部不可见-内部操作的。

十、 设计关联

• 对象模型中的关联指定了对象相互间的访问路径。
• 在面向对象设计过程中，必须确定实现关联的具体策略。

为了更好地设计实现关联的途径，首先应该分析使用关联的方式。
　　　1. 关联的遍历在应用系统中，使用关联有两种可能的方式：单向遍历和双向遍历。
　　在应用系统中，某些关联只需要单向遍历，这种单向关联实现起来比较简单，另外一些关联可能需要双向遍历，双向关联实现起来稍微麻烦一些。
　　　2. 实现单向关联
　　用指针可以方便地实现单向关联。
如果关联的重数是一元的(如图11.8所示)，则实现关联的指针是一个简单指针。

　　　　　　　　　　　　　　　　　　用指针实现单向关联

　　　　　　　　　　　　　　　　图11.9 用指针实现双向关联

对象模型中的关联指定了对象相互间的访问路径。
　　在面向对象设计过程中，必须确定实现关联的具体策略。
　　为了更好地设计实现关联的途径，首先应该分析使用关联的方式。

（一） 关联的遍历

在应用系统中，使用关联有两种可能的方式：
　　　　　单向遍历和双向遍历。
　　在应用系统中，某些关联只需要单向遍历，这种单向关联实现起来比较简单，另外一些关联可能需要双向遍历，双向关联实现起来稍微麻烦一些。

（二） 实现单向关联

用指针可以方便地实现单向关联。
如果关联的重数是一元的(如图11.8所示)，则实现关联的指针是一个简单指针。

（三） 实现双向关联

许多关联都需要双向遍历，当然，两个方向遍历的频度往往并不相同。实现双向关联有下列3种方法：
　　　(1) 只用属性实现一个方向的关联，当需要反向遍历时就执行一次正向查找。如果两个方向遍历的频度相差很大，而且需要尽量减少存储开销和修改时的开销，则这是一种很有效的实现双向关联的方法。
　　　(2) 两个方向的关联都用属性实现。具体实现方法已在前面讲过，如图11.9所示。这种方法能实现快速访问，但是，如果修改了一个属性，则相关的属性也必须随之修改，才能保持该关联链的一致性。当访问次数远远多于修改次数时，这种实现方法很有效。
　　　(3) 用独立的关联对象实现双向关联。关联对象不属于相互关联的任何一个类，它是独立的关联类的实例，如图所示。

（四） 关联对象的实现

可以引入一个关联类来保存描述关联性质的信息，关联中的每个连接对应着关联类的一个对象。
　　实现关联对象的方法取决于关联的重数。对于一对一关联来说，关联对象可以与参与关联的任一个对象合并。对于一对多关联来说，关联对象可以与“多”端对象合并。如果是多对多关联，则关联链的性质不可能只与一个参与关联的对象有关，通常用一个独立的关联类来保存描述关联性质的信息，这个类的每个实例表示一条具体的关联链及该链的属性。