第十一章：面向对象设计

第十一章：面向对象设计

一、面向对象设计的概念

1.定义

• 设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。从面向对象分析到面向对象设计是一个逐渐扩充模型的过程，即面向对象设计就是用面向对象观点建立求解域模型的过程。

2.设计与分析的关系

• (1)分析结果可以直接映射成设计结果，而在设计过程中又会加深和补充对系统需求的理解，进一步完善分析结果。
  (2)分析和设计活动是一个多次反复迭代的过程。
  (3)分析是提取和整理用户需求，并建立问题域精确模型的过程。设计则是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。

3.分类

• (1)系统设计：确定实现系统的策略和目标系统的高层结构。
  (2)对象设计：确定解空间中的类、关联、接口形式及实现服务的算法。

二、面向对象设计的准则

1.优秀设计的定义

• 优秀设计是权衡了各种因素，从而使得系统在其整个生命周期中的总开销最小的设计。优秀软件设计的一个主要特点就是容易维护。

2.准则

• (1)模块化
  面向对象软件开发模式支持了把系统分解成模块设计的原理，对象是面向对象软件系统中的模块，它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块。
• (2)抽象
  面向对象的程序设计语言不仅支持过程抽象，而且支持数据抽象，对象类实际上是具有继承机制的抽象数据类型，它对外开放的公共接口构成了类的规格说明(协议),这种接口规定了外界可以使用的合法操作符，利用这些操作符可以对类实例中包含的数据进行操作。
  ①规格说明抽象
  使用者无须知道操作符的实现算法和类中数据元素的具体表示方法，就可以通过这些操作符使用类中定义的数据，这种抽象称为规格说明抽象。
  ②参数化抽象
  指当描述类的规格说明时并不具体指定所要操作的数据类型，而是把数据类型作为参数，使得类的抽象程度更高，应用范围更广，可重用性更高。
• (3)信息隐藏
  在面向对象的软件中，信息隐藏通过对象的封装来实现，即类结构分离了接口与实现，从而支持了信息隐藏。对于类，属性的表示方法和操作的实现算法都是隐藏的。
• (4)弱耦合
  耦合是指一个软件结构内不同模块之间互连的紧密程度。在面向对象方法中，对象是最基本的模块，因此，耦合主要指不同对象之间相互关联的紧密程度。弱耦合是优秀设计的一个重要标准。
  ①交互耦合
  对象间的耦合通过消息连接来实现，则这种耦合是交互耦合。要使交互耦合尽可能松散，必须遵守下述准则。
  a.尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度。
  b.减少对象发送或接收的消息数。
  ②继承耦合
  继承是一般类与特殊类之间耦合的一种形式。通过继承关系结合起来的基类和派生类构成了系统中粒度更大的模块，因此，它们彼此之间应该结合得越紧密越好。
• (5)强内聚
  内聚衡量一个模块内各个元素彼此结合的紧密程度，在设计时应该力求做到高内聚。在面向对象设计中存在下述3种内聚：
  ①服务内聚
  一个服务应该完成一个且仅完成一个功能。
  ②类内聚
  设计类的准则是，一个类应该只有一个用途，它的属性和服务应该是高内聚的。如果某个类有多个用途，应该把它分解成多个专用的类。
  ③一般—特殊内聚
  设计出的一般一特殊结构应该是对相应的领域知识的正确抽取。紧密的继承耦合与高度的一般一特殊内聚是一致的。
• (6)可重用
  软件重用是提高软件开发生产率和目标系统质量的重要途径。重用基本上从设计阶段开始。重用有两方面的含义：
  ①尽量使用已有的类。
  ②如果需要创建新类，则在设计这些新类的协议时应该考虑将来的可重复使用性。

三、启发规则

1.必要性

• 总结人类使用面向对象方法学开发软件的经验，可以得出几条启发规则，它们往往能帮助软件开发人员提高面向对象设计的质量。

2.具体规则

• (1)设计结果应该清晰易懂
  使设计结果清晰、易读、易懂是提高软件可维护性和可重用性的重要措施。保证设计结果清晰易懂的主要因素如下：
  ①用词一致
  应该使名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字。不同类中相似服务的名字应该相同。
  ②使用已有的协议
  如果开发同一软件的其他设计人员已经建立了类的协议，或者在所使用的类库中已有相应的协议，则应该使用这些已有的协议。
  ③减少消息模式的数目
  如果已有标准的消息协议，设计人员应该遵守这些协议。
  ④避免模糊的定义
  一个类的用途应该是有限的，而且应该从类名可以较容易地推出它的用途。
• (2)一般一特殊结构的深度应适当
  ①使类等级中包含的层次数适当，类等级中包含的层次保持在7±2。
  ②不能仅从方便编码的角度出发随意创建派生类，应该使一般一特殊结构与领域知识或常识保持一致。
• (3)设计简单的类
  应该尽量设计小而简单的类，以便开发和管理。为使类保持简单，应注意以下几点：
  ①避免包含过多的属性
  属性过多通常表明这个类过分复杂了，它所完成的功能可能太多了。
  ②有明确的定义
  为了使类的定义明确，分配给每个类的任务应该简单，最好能使用一两个简单语句描述它的任务。
  ③简化对象之间的合作关系
  如果需要多个对象协同配合才能做好一件事，则破坏了类的简明性和清晰性。
  ④不要提供太多服务(公共服务不超过7个)
  一个类提供的服务过多，同样表明这个类过分复杂。典型地，一个类提供的公共服务不超过7个。
  ⑤划分“主题”。
• (4)使用简单的协议
  一般来说，消息中的参数不要超过3个。通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。
• (5)使用简单的服务
  ①避免使用复杂的服务。
  ②需要在服务中使用CASE语句时，应用一般—特殊结构代替这个类。
• (6)把设计变动减至最小
  在设计的早期阶段，变动较大，随着时间推移，设计方案日趋成熟，改动也越来越小了。

四、软件重用

1.概述

• (1)重用
  重用也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。软件重用可分为以下3个层次：
  ①知识重用；
  ②方法和标准的重用；
  ③软件成分的重用。
  其中知识重用以及方法和标准的重用层次属于知识工程研究的范畴。
• (2)软件成分的重用级别
  ①代码重用
  a.定义
  代码重用是调用库中的模块。
  b.形式
  第一，源代码剪贴
  是最原始的重用形式，复制或修改源代码时可能出错，且存在严重的配置管理问题。
  第二，源代码包含
  配置管理问题有所缓解，所有包含它的程序都必须重新编译。
  第三，继承
  无须修改已有的代码，就可扩充或具体化在库中找出的类。基本上不存在配置管理问题。
  ②设计结果重用
  重用某个软件系统的设计模型(求解域模型),有助于把一个应用系统移植到完全不同的软硬件平台上。
  ③分析结果重用
  是一种更高级别的重用，重用某个系统的分析模型。特别适用于用户需求未改变，但系统体系结构发生了根本变化的场合。
• (3)典型的可重用软件成分
  可能被重用的软件成分主要有以下10种：
  ①项目计划
  软件项目计划的基本结构和许多内容都是可以跨项目重用的。
  ②成本估计
  在只做极少修改或根本不做修改的情况下，重用对该功能的成本估计结果。
  ③体系结构
  创建一组类属的体系结构模板，并把那些模板作为可重用的设计框架。
  ④需求模型和规格说明
  类和对象的模型、规格说明、用传统软件工程方法开发的分析模型是重用的候选者。
  ⑤设计
  用传统方法开发的体系结构、数据、接口和过程设计结果，是重用的候选者。
  ⑥源代码
  用兼容的程序设计语言书写的、经过验证的程序构件，是重用的候选者。
  ⑦用户文档和技术文档
  即使针对的应用是不同的，也经常有可能重用用户文档和技术文档的大部分。
  ⑧用户界面
  这可能是最广泛被重用的软件成分，GUI(图形用户界面)软件经常被重用。因为它可占到一个应用程序的
  60%代码量。
  ⑨数据
  被重用的数据包括：内部表、列表和记录结构，以及文件和完整的数据库。
  ⑩测试用例
  一旦设计或代码构件将被重用，相关的测试用例应该“附属于”它们也被重用。

2.类构件

• (1)可重用软构件的特点
  为使软构件也像硬件集成的电路那样，能在构造各种各样的软件系统时方便地重复使用，就必须使它们满足下列要求.
  ①模块独立性强
  具有单一、完整的功能，且经过反复测试被确认是正确的。它应该是一个不受或很少受外界干扰的封装体，其内部实现在外面是不可见的。
  ②具有高度可塑性
  可重用的软构件必须具有高度可裁剪性，即必须提供为适应特定需求而扩充或修改已有构件的机制，而且所提供的机制必须使用起来简单方便。
  ③接口清晰、简明、可靠
  软构件应该提供清晰、简明、可靠的对外接口，而且还应该有详尽的文档说明，以方便用户使用。
• (2)类构件的重用方式
  面向对象技术中的“类”,是比较理想的可重用软构件，称之为类构件。类构件有实例重用、继承重用和多态重用3种重用方式。
  ①实例重用
  除了用已有的类为样板直接创建该类的实例之外，还可以用几个简单的对象作为类的成员创建出一个更复杂的类。
  ②继承重用
  当已有的类构件不能通过实例重用方式满足当前系统的需求时，利用继承机制从已有类派生出符合需要的子类，是安全修改已有的类构件并获得可在当前系统中使用的类构件的有效手段。
  ③多态重用
  在设计类构件时应把注意力集中在下列这些可能妨碍重用的操作上：
  a.与表示方法有关的操作。
  b.与数据结构、数据大小等因素有关的操作。
  c.与外部设备有关的操作。
  d.实现算法在将来可能会改变的核心操作。

3.软件重用的效益

• (1)质量
  随着每一次重用，都会有一些错误被发现并被清除，构件的质量也会随之改善。随着时间的推移，构件将变成实质上无错误的。重用给软件产品的质量和可靠性带来实质性的提高。
• (2)生产率
  把可重用的软件成分应用于软件开发的全过程时，创建计划、模型、文档、代码和数据所花费的时间将减少，从而用较少的投入给客户提供相同级别的产品，故生产率得到了提高。
• (3)成本
  软件重用带来的净成本节省可以用下式估算：
  C=Cs-Cr-Cd
  其中，Cs是项目从头开发时所需要的成本；Cr是与重用相关联的成本；Cd是交付给客户的软件的实际成本。
  与重用相关联的成本C,主要包括下述成本：
  ①领域分析与建模的成本。
  ②设计领域体系结构的成本。
  ③为方便重用而增加的文档的成本。
  ④维护和完善可重用的软件成分的成本。
  ⑤为从外部获取构件所付出的版税和许可证费用。
  ⑥创建及运行重用库的费用。
  ⑦对设计和实现可重用构件的人员的培训费用。

五、系统分解

1.分解的思想

• 在设计比较复杂的应用系统时，先把系统分解成若干个较小部分，然后分别设计每个部分。这样做有利于降低设计的难度，有利于分工协作，也有利于维护人员对系统理解和维护。

2.子系统

• (1)定义
  系统的主要组成部分称为子系统，通常根据所提供的功能来划分子系统。
• (2)划分原则
  ①根据所提供的功能来划分子系统，子系统数目应该与系统规模基本匹配。
  ②各个子系统之间应该具有尽可能简单、明确的接口。
  ③应该尽量减少子系统彼此间的依赖性。

3.分解面向对象设计模型

• (1)表示
  典型的面向对象设计模型，如图11.2所示。
  ①面向对象设计模型由主题、类与对象、结构、属性、服务5个层次组成。这5个层次一层比一层表示的细节更多，可以把这5个层次想象为整个模型的水平切片。
  ②面向对象设计模型在逻辑上都由4大部分组成，分别对应于组成目标系统的4个子系统，即问题域子系统、人机交互子系统、任务管理子系统和数据管理子系统。

  • 图11.2典型的面向对象设计模型
    

• (2)子系统间交互方式
  在软件系统中，子系统之间的交互有两种可能的方式，分别是客户一供应商(Client-supplier)关系和平等伙伴(peer-to-peer)关系。
  ①客户—供应商关系(较好)
  作为"客户"的子系统调用作为"供应商"的子系统，后者完成某些服务工作并返回结果。作为客户的子系统必须了解作为供应商的子系统的接口，后者却无须了解前者的接口。
  ②平等伙伴关系
  每个子系统都可能调用其他子系统，每个子系统都必须了解其他子系统的接口。由于各个子系统需要相互了解对方的接口，子系统之间的交互复杂，且还可能存在通信环路。
  注意：单项交互比双向交互更容易理解，也更容易设计和修改，因此应该尽量使用客户一供应商关系。

• (3)组织系统的方案
  把子系统组织成完整的系统时，可以使用水平层次组织和垂直块组织两种方案。
  ①层次组织
  a.定义
  软件系统组织成一个层次系统，每层是一个子系统。上层在下层的基础上建立，下层为实现上层功能而提供必要的服务。每一层内所包含的对象，彼此间相互独立，而处于不同层次上的对象，彼此间有关联。在上、下层之间存在客户一供应商关系。低层子系统提供服务，上层子系统使用下层提供的服务。
  b.模式分类
  第一，封闭式
  每层子系统仅仅使用其直接下层提供的服务。降低了各层次之间的相互依赖性，更容易理解和修改。
  第二，开放式
  子系统可以使用处于其下面的任何一层子系统所提供的服务。优点是减少了需要在每层重新定义的服务数目，使系统更高效更紧凑。但其不符合信息隐藏原则。
  ②块状组织
  把软件系统垂直地分解成若干个相对独立的、弱耦合的子系统，一个子系统相当于一块，每块提供一种类型的服务。
  ③层次和块的组合
  当混合使用层次结构和块状结构时，同一层次可以由若干块组成，而同一块也可以分为若干层。
  ④设计系统的拓扑结构
  典型的拓扑结构有管道形、树形、星形等。应采用与问题结构相适应的、尽可能简单的拓扑结构，以减少子系统之间的交互数量。

六、设计问题域子系统

1.概念

• (1)面向对象分析所得出的问题域精确模型，为设计问题域子系统建立了完整的框架。
  (2)保持面向对象分析所建立的问题域结构。
  (3)面向对象设计仅需从实现角度对问题域模型做一些补充或修改。
  (4)问题域子系统过分复杂庞大时，应该把它进一步分解成若干个更小的子系统。

2.对问题域模型进行的处理

• (1)调整需求
  ①需进行修改的情况
  a.用户需求或外部环境发生了变化。
  b.分析员对问题域理解不透彻或不能完整、准确地反映用户的真实需求。
  ②方法
  简单地修改面向对象分析结果，然后再把这些修改反映到问题域子系统中。
• (2)重用已有的类
  重用已有类的主要步骤：
  ①在已有类中找出与问题域内某个最相似的类作为被重用的类。
  ②从被重用的类派生出问题域类。
  ③简化对问题域类的定义(从被重用的类继承的属性和服务无须再定义)。
  ④修改与问题域类相关的关联，必要时改为与被重用的类相关的关联。
• (3)把问题域类组合在一起
  ①增添一个根类而把若干个问题域类组合在一起。
  ②引入根类或基类的办法，可以为一些具体类建立一个公共的协议。
• (4)增添一般化类以建立协议
  在设计过程中常常发现，一些具体类需要有一个公共的协议，可以引入附加类以便建立这个协议。
• (5)调整继承层次
  如果面向对象分析模型中包含了多重继承关系，然而所使用的程序设计语言却并不提供多重继承机制，则必须修改面向对象分析的结果。具体如下：
  ①多重继承机制
  使用多重继承机制时，应该避免出现属性及服务的命名冲突。
  ②单继承机制
  使用多重继承机制时，必须把面向对象分析模型中的多重继承结构转换成单继承结构。

七、设计人机交互子系统

1.概念

• (1)主要内容
  在面向对象设计过程中，对系统的人机交互子系统进行详细设计，以确定人机交互的细节，其中包括指定窗口和报表的形式、设计命令层次等项内容。
• (2)重要性
  人机界面设计得好，则会使系统对用户产生吸引力，用户在使用系统的过程中会感到兴奋，能够激发用户的创造力，提高工作效率；人机界面设计得不好，用户在使用过程中就会感到不方便、不习惯，甚至会产生厌烦和恼怒的情绪。
  注意：使用由原型支持的系统化的设计策略，是成功地设计人机交互子系统的关键。

2.设计策略

• (1)分类用户
  应该把将来可能与系统交互的用户按技能水平，或按职务，或按所属集团进行分类。
• (2)描述用户
  了解将来使用系统的每类用户的情况，把用户类型、使用目的、特征、关键的成功因素、技能水平、完成本职工作的脚本的信息记录下来。
• (3)设计命令层次
  ①研究现有的人机交互含义和准则
  设计图形用户界面时，应该遵守广大用户习惯的约定，这样才会被用户接受和喜爱。
  ②确定初始的命令层次
  命令层次实质上是用抽象机制组织起来的、可供选用的服务的表示形式，设计命令层次时，通常先从对服务的过程抽象着手，然后进一步修改它们，以适合具体应用环境的需要。
  ③精化命令层次
  为进一步修改完善初始的命令层次，应该考虑次序、整体部分关系、宽度和深度等因素。
• (4)设计人机交互类
  人机交互类与所使用的操作系统及编程语言密切相关

八、设计任务管理子系统

1.设计的必要性

• (1)许多对象之间往往存在相互依赖关系。
  (2)在实际使用的硬件中，可能仅由一个处理器支持多个对象。

2.设计步骤

• (1)分析并发性
  ①并发性
  如果两个对象彼此间不存在交互，或它们同时接受事件，则它们在本质上是并发的。
  ②方法
  a.通过面向对象分析建立起来的动态模型，是分析并发性的主要依据。
  b.通过检查各个对象的状态图及它们之间交换的事件，能够把若干个非并发的对象归并到一条控制线中。
  ③控制线
  控制线是一条遍及状态图集合的路径，在这条路径上每次只有一个对象是活动的。在计算机系统中用进程实现控制线。把多个任务的并发执行称为多任务。
• (2)设计任务管理子系统
  ①确定事件驱动型任务
  a.定义
  某些任务是由事件驱动的，这类任务可能主要完成通信工作。
  b.具体任务
  第一，任务处于睡眠状态，等待来自数据线或其他数据源的中断。
  第二，一旦接收到中断就唤醒了该任务，接收数据并把数据放入内存缓冲区或其他目的地，通知需要知道这件事的对象，然后该任务又回到睡眠状态。
  ②确定时钟驱动型任务
  a.定义
  某些任务每隔一定时间间隔就被触发以执行某些处理。
  b.具体任务
  第一，任务设置了唤醒时间后进入睡眠状态，等待来自系统的中断。
  第二，接收到这种中断，任务就被唤醒并做它的工作，通知有关的对象，然后该任务又回到睡眠状态。
  ③确定优先任务
  优先任务可以满足高优先级或低优先级的处理需求。
  a.高优先级
  有些服务是优先级的，为了在严格限定的时间内完成，把这类服务分离成独立的任务。
  b.低优先级
  与高优先级相反，有些服务是低优先级的，属于低优先级处理。设计时用额外的任务把其分离出来。
  ④确定关键任务
  a.定义
  关键任务是有关系统成功或失败的关键处理，这类处理通常都有严格的可靠性要求。
  b.处理方法
  在设计过程中用额外的任务把这样的关键处理分离出来，以满足高可靠性处理的要求。
  ⑤确定协调任务
  a.定义
  当系统中存在3个以上任务时，就应该增加一个任务，用它作为协调任务。
  b.优缺点
  优点：有助于把不同任务之间的协调控制封装起来。
  缺点：会增加系统的总开销。
  c.工具
  使用状态转换矩阵可以比较方便地描述该任务的行为。这类任务仅做协调工作，不要让它再承担其他服务工作。
  ⑥尽量减少任务数
  a.定义
  必须仔细分析和选择每个确实需要的任务。应该使系统中包含的任务数尽量少。
  b.原因
  设计者为了自己处理时的方便而轻率地定义过多的任务。这样做加大了设计工作的技术复杂度，并使系统变得不易理解，也加大了系统维护的难度。
  ⑦确定资源需求
  a.通过计算系统载荷，来估算所需要的固件的处理能力。
  b.综合权衡一致性、成本、性能以及未来的可扩充性和可修改性，决定资源需求。
  c.综合考虑各种因素，以决定哪些子系统用硬件实现，哪些子系统用软件实现。

九、设计数据管理子系统

1.概念

• 数据管理子系统是系统存储或检索对象的基本设施，它建立在某种数据存储管理系统之上，并且隔离了数据存储管理模式的影响。

2.选择数据存储管理模式

• (1)文件管理系统
  ①优点
  文件管理系统是操作系统的一个组成部分，使用它长期保存数据具有成本低和简单的优点。
  ②缺点
  文件操作的级别低，为提供适当的抽象级别还必须编写额外的代码，不同操作系统的文件管理系统往往有明显差异。
• (2)关系数据库管理系统
  ①理论基础
  关系数据库管理系统的理论基础是关系代数。
  ②优点
  a.理论基础坚实。
  b.提供了各种最基本的数据管理功能，例如中断恢复，多用户共享，多应用共享，完整性，事务支持等。
  c.为多种应用提供了一致的接口。
  d.标准化的语言。
  ③缺点
  a.运行开销大：即使完成简单的事务，也需要较长的时间。
  b.不能满足高级应用的需求：关系数据库管理系统是为商务应用服务的，商务应用中数据量虽大但数据结构却比较简单。
  c.与程序设计语言的连接不自然：SQL语言支持面向集合的操作，是一种非过程化的语言；然而大多数程序设计语言本质上却是过程性的，每次只能处理一个记录。
• (3)面向对象数据库管理系统
  ①扩展的关系数据库管理系统
  在关系数据库的基础上，增加了抽象数据类型和继承机制，此外还增加了创建及管理类和对象的通用服务。
  ②扩展的面向对象程序设计语言
  扩充了面向对象程序设计语言的语法和功能，增加了在数据库中存储和管理对象的机制。可以使用统一的面向对象观点进行设计，不需要区分存储数据结构和程序数据结构。

3.设计数据管理子系统

• (1)设计数据格式
  ①文件系统
  a.定义第一范式表：列出每个类的属性表；把属性表规范成第一范式，从而得到第一范式表的定义。
  b.为每个第一范式表定义一个文件。
  c.测量性能和需要的存储容量。
  d.修改原设计的第一范式，以满足性能和存储需求。
  必要时把泛华结构的属性压缩在单个文件中，以减少文件数量；必要时把某些属性组合在一起，并用某种编码值表示这些属性，而不再使用独立的域表示每个属性。
  ②关系数据库管理系统
  a.定义第三范式表：列出每个类的属性表；把属性表规范成第三范式，从而得出第三范式表的定义。
  b.为每个第三范式表定义一个数据库表。
  c.测量性能和需要的存储容量。
  d.修改先前设计的第三范式，以满足性能和存储需求。
  ③面向对象数据库管理系统
  a.扩展的关系数据库途径：使用与关系数据库管理系统相同的方法。
  b.扩展的面向对象程序设计语言途径：不需要规范化属性的步骤。
• (2)设计相应的服务
  使用不同数据存储管理模式时的设计要点如下：
  ①文件系统
  a.被存储的对象需要知道打开哪个文件，怎样把文件定位到正确的记录上，怎样检索出旧值，以及怎样用现有值更新它们。
  b.定义一个ObjectServer类，并创建它的实例。
  ②关系数据库管理系统
  a.被存储的对象，应该知道访问哪些数据库表，怎样访问所需要的行，怎样检索出旧值，以及怎样用现有值更新它们。
  b.定义一个ObjectServer类，并声明它的对象。
  ③面向对象数据库管理系统
  a.扩展的关系数据库途径：与使用关系数据库管理系统时方法相同
  b.扩展的面向对象程序设计语言途径：无须增加服务，只需给长期保存的对象加个标记，然后由面向对象数据库管理系统负责存储和恢复这类对象。

十、设计类中的服务

1.确定类中应有的服务

• (1)确定服务的总体思想
  ①对象模型是进行对象设计的基本框架。必须把动态模型中对象的行为以及功能模型中的数据处理转换成由适当的类所提供的服务。
  ②动态模型中状态图中的状态转换执行对象服务的结果。
  ③功能模型指明了系统必须提供的服务。
• (2)确定操作目标对象的启发规则
  ①如果某个处理的功能是从输入流中抽取一个值，则该输入流就是目标对象。
  ②如果某个处理具有类型相同的输入流和输出流，而且输出流实质上是输入流的另一种形式，则该输入输出流就是目标对象。
  ③如果某个处理从多个输入流得出输出值，则该处理是输出类中定义的一个服务。
  ④如果某个处理把对输入流处理的结果输出给数据存储或动作对象，则该数据存储或动作对象就是目标对象。
• (3)确定处理归属的启发规则
  ①如果处理影响或修改了一个对象，则最好把该处理与处理的目标联系在一起。
  ②考察处理涉及的对象类及这些类之间的关联，从中找出处于中心地位的类。

2.设计实现服务的方法

• (1)设计实现服务的算法
  主要考虑下列因素：
  ①算法复杂度：选用复杂度较低(效率较高)的算法，但不能过分追求高效率，应以能满足用户需求为准。
  ②容易理解与容易实现：容易理解与容易实现的要求往往与高效率有矛盾，设计者应该对这两个因素适当折衷。
  ③易修改：预测将来可能做的修改，并在设计时预先做些准备。
• (2)选择数据结构
  选择能够方便、有效地实现算法的物理数据结构。
• (3)算法与数据结构的关系
  主要考虑下列因素：
  ①分析问题寻找数据特点，提炼出所有可行有效的算法。
  ②定义与所提炼算法相关联的数据结构。
  ③依据此数据结构进行算法的详细设计。
  ④进行一定规模的实验与评测。
  ⑤确定最佳设计。
• (4)定义内部类和内部操作
  增添一些用来存放在执行算法过程中所得出的中间结果的类，其需求陈述中没有提到。复杂操作往往可以用简单对象上的更低层操作来定义，因此，在分解高层操作时常常引入新的低层操作。

十一、设计关联

1.关联

• (1)定义
  在对象模型中，关联是联结不同对象的纽带，它指定了对象相互间的访问路径。
• (2)确定实现关联的策略
  ①选定一个全局性的策略统一实现所有关联。
  ②分别为每个关联选择具体的实现策略，以与它在应用系统中的使用方式相适应。

2.使用关联的方式

• (1)关联的遍历
  ①单向遍历
  ②双向遍历
  在使用原型法开发软件的时候，原型中所有关联都应该是双向的，以便于增加新的行为，快速地扩充和修改原型。
• (2)实现单向关联
• (3)实现双向关联
• (4)关联对象的实现

十二、设计优化

1.确定优先级

• (1)必要性
  系统的各项质量指标并不是同等重要的，必须确定各项质量指标的优先级，以便在优化设计时制定折中方案。系统的整体质量与制定的折中方案密切相关。最终产品成功与否，在很大程度上取决于是否选择好了系统目标。
• (2)方法
  在效率和清晰度之间寻求适当的折中方案。在折中方案中设置的优先级应当是模糊的。

2.提高效率的几项技术

• (1)增加冗余关联以提高访问效率。
  (2)调整查询次序。
  (3)保留派生属性。

3.调整继承关系

• (1)继承关系
  继承关系能够为一个类族定义一个协议，并能在类之间实现代码共享以减少冗余。一个基类和它的子孙类在一起称为一个类继承。在面向对象设计中，建立良好的类继承是非常重要的。利用类继承能够把若干个类组织成一个逻辑结构。
• (2)建立类继承

云盘地址地址