第11章 面向对象设计

第11章面向对象设计11.1面向对象设计的准则11.2启发规则11.3软件重用11.4系统分解11.5设计问题域子系统11.6设计人机交互子系统11.7设计任务管理子系统11.8设计数据管理子系统11.9设计类中的服务11.10设计关联11.11设计优化11.12小结习题如前所述，分析是提取和整理用户需求，并建立问题域精确模型的过程。设计则是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的过程。从面向对象分析到面向对象设计(OOD)，是一个逐渐扩充模型的过程。或者说，面向对象设计就是用面向对象观点建立求解域模型的过程。尽管分析和设计的定义有明显区别，但是在实际的软件开发过程中二者的界限是模糊的。许多分析结果可以直接映射成设计结果，而在设计过程中又往往会加深和补充对系统需求的理解，从而进一步完善分析结果。因此，分析和设计活动是一个多次反复迭代的过程。面向对象方法学在概念和表示方法上的一致性，保证了在各项开发活动之间的平滑(无缝)过渡，领域专家和开发人员能够比较容易地跟踪整个系统开发过程，这是面向对象方法与传统方法比较起来所具有的一大优势。生命周期方法学把设计进一步划分成总体设计和详细设计两个阶段，类似地，也可以把面向对象设计再细分为系统设计和对象设计。系统设计确定实现系统的策略和目标系统的高层结构。对象设计确定解空间中的类、关联、接口形式及实现服务的算法。系统设计与对象设计之间的界限，比分析与设计之间的界限更模糊，本书不再对它们加以区分。本章首先讲述为获得优秀设计结果应该遵循的准则，然后具体讲述面向对象设计的任务和方法。所谓优秀设计，就是权衡了各种因素，从而使得系统在其整个生命周期中的总开销最小的设计。对大多数软件系统而言，60%以上的软件费用都用于软件维护，因此，优秀软件设计的一个主要特点就是容易维护。本书第5章曾经讲述了指导软件设计的几条基本原理，这些原理在进行面向对象设计时仍然成立，但是增加了一些与面向对象方法密切相关的新特点，从而具体化为下列的面向对象设计准则。11.1面向对象设计的准则1.模块化面向对象软件开发模式，很自然地支持了把系统分解成模块的设计原理：对象就是模块。它是把数据结构和操作这些数据的方法紧密地结合在一起所构成的模块。2.抽象面向对象方法不仅支持过程抽象，而且支持数据抽象。类实际上是一种抽象数据类型，它对外开放的公共接口构成了类的规格说明(即协议)，这种接口规定了外界可以使用的合法操作符，利用这些操作符可以对类实例中包含的数据进行操作。使用者无须知道这些操作符的实现算法和类中数据元素的具体表示方法，就可以通过这些操作符使用类中定义的数据。通常把这类抽象称为规格说明抽象。此外，某些面向对象的程序设计语言还支持参数化抽象。所谓参数化抽象，是指当描述类的规格说明时并不具体指定所要操作的数据类型，而是把数据类型作为参数。这使得类的抽象程度更高，应用范围更广，可重用性更高。例如，C++语言提供的“模板”机制就是一种参数化抽象机制。3.信息隐藏在面向对象方法中，信息隐藏通过对象的封装性实现：类结构分离了接口与实现，从而支持了信息隐藏。对于类的用户来说，属性的表示方法和操作的实现算法都应该是隐藏的。4.弱耦合耦合指一个软件结构内不同模块之间互连的紧密程度。在面向对象方法中，对象是最基本的模块，因此，耦合主要指不同对象之间相互关联的紧密程度。弱耦合是优秀设计的一个重要标准，因为这有助于使得系统中某一部分的变化对其他部分的影响降到最低程度。在理想情况下，对某一部分的理解、测试或修改，无须涉及系统的其他部分。如果一类对象过多地依赖其他类对象来完成自己的工作，则不仅给理解、测试或修改这个类带来很大困难，而且还将大大降低该类的可重用性和可移植性。显然，类之间的这种相互依赖关系是紧耦合的。当然，对象不可能是完全孤立的，当两个对象必须相互联系相互依赖时，应该通过类的协议(即公共接口)实现耦合，而不应该依赖于类的具体实现细节。一般说来，对象之间的耦合可分为两大类，下面分别讨论这两类耦合：(1)交互耦合如果对象之间的耦合通过消息连接来实现，则这种耦合就是交互耦合。为使交互耦合尽可能松散，应该遵守下述准则：尽量降低消息连接的复杂程度。应该尽量减少消息中包含的参数个数，降低参数的复杂程度。减少对象发送(或接收)的消息数。(2)继承耦合与交互耦合相反，应该提高继承耦合程度。继承是一般化类与特殊类之间耦合的一种形式。从本质上看，通过继承关系结合起来的基类和派生类，构成了系统中粒度更大的模块。因此，它们彼此之间应该结合得越紧密越好。为获得紧密的继承耦合，特殊类应该确实是对它的一般化类的一种具体化。因此，如果一个派生类摒弃了它基类的许多属性，则它们之间是松耦合的。在设计时应该使特殊类尽量多继承并使用其一般化类的属性和服务，从而更紧密地耦合到其一般化类。5.强内聚内聚衡量一个模块内各个元素彼此结合的紧密程度。也可以把内聚定义为：设计中使用的一个构件内的各个元素，对完成一个定义明确的目的所做出的贡献程度。在设计时应该力求做到高内聚。在面向对象设计中存在下述3种内聚。（1）服务内聚。一个服务应该完成一个且仅完成一个功能。（2）类内聚。设计类的原则是，一个类应该只有一个用途，它的属性和服务应该是高内聚的。类的属性和服务应该全都是完成该类对象的任务所必需的，其中不包含无用的属性或服务。如果某个类有多个用途，通常应该把它分解成多个专用的类。（3）一般-特殊内聚。设计出的一般-特殊结构，应该符合多数人的概念，更准确地说，这种结构应该是对相应的领域知识的正确抽取。一般说来，紧密的继承耦合与高度的一般-特殊内聚是一致的。6.可重用软件重用是提高软件开发生产率和目标系统质量的重要途径。重用基本上从设计阶段开始。重用有两方面的含义：一是尽量使用已有的类(包括开发环境提供的类库，及以往开发类似系统时创建的类)，二是如果确实需要创建新类，则在设计这些新类的协议时，应该考虑将来的可重复使用性。关于软件重用问题，将在11.3节进一步讨论。人们使用面向对象方法学开发软件的历史虽然不长，但也积累了一些经验。总结这些经验得出了几条启发规则，它们往往能帮助软件开发人员提高面向对象设计的质量。1.设计结果应该清晰易懂使设计结果清晰、易读、易懂，是提高软件可维护性和可重用性的重要措施。显然，人们不会重用那些他们不理解的设计。保证设计结果清晰易懂的主要因素如下。11.2启发规则（1）用词一致。应该使名字与它所代表的事物一致，而且应该尽量使用人们习惯的名字。不同类中相似服务的名字应该相同。（2）使用已有的协议。如果开发同一软件的其他设计人员已经建立了类的协议，或者在所使用的类库中已有相应的协议，则应该使用这些已有的协议。（3）减少消息模式的数目。如果已有标准的消息协议，设计人员应该遵守这些协议。如果确需自己建立消息协议，则应该尽量减少消息模式的数目，只要可能，就使消息具有一致的模式，以利于读者理解。（4）避免模糊的定义。一个类的用途应该是有限的，而且应该从类名可以较容易地推想出它的用途。2.一般-特殊结构的深度应适当应该使类等级中包含的层次数适当。一般说来，在一个中等规模(大约包含100个类)的系统中，类等级层次数应保持为7±2。不应该仅仅从方便编码的角度出发随意创建派生类，应该使一般-特殊结构与领域知识或常识保持一致。3.设计简单的类应该尽量设计小而简单的类，以便于开发和管理。当类很大的时候，要记住它的所有服务是非常困难的。经验表明，如果一个类的定义不超过一页纸(或两屏)，则使用这个类是比较容易的。为使类保持简单，应该注意以下几点。(1)避免包含过多的属性。属性过多通常表明这个类过分复杂了，它所完成的功能可能太多了。(2)有明确的定义。为了使类的定义明确，分配给每个类的任务应该简单，最好能用一两个简单语句描述它的任务。(3)尽量简化对象之间的合作关系。如果需要多个对象协同配合才能做好一件事，则破坏了类的简明性和清晰性。(4)不要提供太多服务。一个类提供的服务过多，同样表明这个类过分复杂。典型地，一个类提供的公共服务不超过7个。在开发大型软件系统时，遵循上述启发规则也会带来另一个问题：设计出大量较小的类，这同样会带来一定复杂性。解决这个问题的办法，是把系统中的类按逻辑分组，也就是划分“主题”。4.使用简单的协议一般说来，消息中的参数不要超过3个。当然，不超过3个的限制也不是绝对的，但是，经验表明，通过复杂消息相互关联的对象是紧耦合的，对一个对象的修改往往导致其他对象的修改。5.使用简单的服务面向对象设计出来的类中的服务通常都很小，一般只有3～5行源程序语句，可以用仅含一个动词和一个宾语的简单句子描述它的功能。如果一个服务中包含了过多的源程序语句，或者语句嵌套层次太多，或者使用了复杂的CASE语句，则应该仔细检查这个服务，设法分解或简化它。一般说来，应该尽量避免使用复杂的服务。如果需要在服务中使用CASE语句，通常应该考虑用一般-特殊结构代替这个类的可能性。6.把设计变动减至最小通常，设计的质量越高，设计结果保持不变的时间也越长。即使出现必须修改设计的情况，也应该使修改的范围尽可能小。理想的设计变动曲线如图11.1所示。在设计的早期阶段，变动较大，随着时间推移，设计方案日趋成熟，改动也越来越小了。图11.1中的峰值与出现设计错误或发生非预期变动的情况相对应。峰值越高，表明设计质量越差，可重用性也越差。图11.1理想的设计变动情况1.重用重用也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。广义地说，软件重用可分为以下3个层次：11.3软件重用11.3.1概述(1)知识重用(例如，软件工程知识的重用)。(2)方法和标准的重用(例如，面向对象方法或国家制定的软件开发规范的重用)。(3)软件成分的重用。前两个重用层次属于知识工程研究的范畴，本节仅讨论软件成分重用问题。2.软件成分的重用级别软件成分的重用可以进一步划分成以下3个级别：(1)代码重用人们谈论得最多的是代码重用，通常把它理解为调用库中的模块。实际上，代码重用也可以采用下列几种形式中的任何一种：源代码剪贴：这是最原始的重用形式。这种重用方式的缺点，是复制或修改原有代码时可能出错，更糟糕的是，存在严重的配置管理问题，人们几乎无法跟踪原始代码块多次修改重用的过程。源代码包含：许多程序设计语言都提供包含(include)库中源代码的机制。使用这种重用形式时，配置管理问题有所缓解，因为修改了库中源代码之后，所有包含它的程序自然都必须重新编译。继承：利用继承机制重用类库中的类时，无须修改已有的代码，就可以扩充或具体化在库中找出的类，因此，基本上不存在配置管理问题。(2)设计结果重用设计结果重用指的是，重用某个软件系统的设计模型(即求解域模型)。这个级别的重用有助于把一个应用系统移植到完全不同的软硬件平台上。(3)分析结果重用这是一种更高级别的重用，即重用某个系统的分析模型。这种重用特别适用于用户需求未改变，但系统体系结构发生了根本变化的场合。3.典型的可重用软件成分更具体地说，可能被重用的软件成分主要有以下10种：（1）项目计划。软件项目计划的基本结构和许多内容（例如，软件质量保证计划）都是可以跨项目重用的。这样做减少了用于制定计划的时间，也降低了与建立进度表和进行风险分析等活动相关联的不确定性。（2）成本估计。因为在不同项目中经常含有类似的功能，所以有可能在只做极少修改或根本不做修改的情况下，重用对该功能的成本估计结果。（3）体系结构。即使在考虑不同的应用领域时，也很少有截然不同的程序和数据体系结构。因此，有可能创建一组类属的体系结构模板（例如，事务处理体系结构），并把那些模板作为可重用的设计框架。通常把类属的体系结构模板称为领域体系结构。（4）需求模型和规格说明。类和对象的模型及规格说明是明显的重用的候选者，此外，用传统软件工程方法开发的分析模型（例如，数据流图），也是可重用的。（5）设计。用传统方法开发的体系结构、数据、接口和过程设计结果，是重用的候选者，更常见的是，系统和对象设计是可重用的。（