7.2.1    选择需进行模块化的要素
    在前面几章论述了程序和模块相关好坏的标准，并提供了确定子程序和模块质量的检查表，
但并没有给出识别子程序和模块的方法，在本节中，将论述这一问题的指导原则。
自顶向下分解
    把程序分解为子程序的一种流行方法是自顶向下分解，也称为自顶向下设计或逐步求精。
其特点是从关于程序功能的粗略说明出发，逐步推进到程序要做的每一项特定的工作。从粗略
的层次出发往往是指从程序中的“主要”子程序出发，通常，把这个子程序画在结构图的顶部。
    以下是几项在进行自顶向下分解时要牢记的原则：
•  设计高层次。
•  避免特定语言细节。从设计中，不应该看出打算在程序中使用什么语言，或者说当在设
      计中更换要用的语言时，不会产生任何麻烦。
•  暂时不指出下一层次的设计细节（与信息隐含类似）。
•  正规化每个层次。
•  检验每个层次。
•  转移到下一个层次，进行新的求精工作。
自顶向下设计指导原则的依据是：人脑一次只能考虑有限数量的细节。如果你从一个较简
略的子程序开始，逐步把它分解成更加详细的子程序，就不必每次考虑过多的细节。这种方法
也常称之为“分而治之”战术。它对于分层结构往往是最有效的。如图7-2 所示。
从两个方面来看，这种分而治之战术是一个逐次迭代逼近的过程，首先，这是由于往往在
一次分解之后你并不会马上停止，还要进行下几个层次的分解。其次，是由于分解并不是一蹴
而就的，采用某种方法分解一个程序，再看一下效果，然后，又用另外一种方法来分解这个程
序，看效果是否会好些，在几次尝试之后，就有了一个很好的办法，同时也知道为什么这样做。
需要把一个程序分解到什么程度呢？要持续不断地分解，直到看起来下一步进行编码要比
再分解要容易为止，或者到你认为设计已经非常明了详细，对再分解已经感到不耐烦为止，到
这时，可以认为分解已经完成了。由于你比任何人都熟悉这个问题，而且也比任何人都清楚，
因此，你要确保其解决方案是很容易理解的，如果连你都对解决方案有些困惑的话，那么，试
想一下，又有谁会理解它呢？
自底向上合成
    有时候，自顶向下方法过于抽象以至于让人不知从何下手。如果想要进行一些具体的工作，
那么可以试一下自底向上的设计方法，如图7-2 所示。你可以问自己，“这个系统需要做什么？”
毫无疑问，你能够回答这个问题。你可以识别出系统需要具备的较低层次的功能，例如，你可
能知道这个系统需要进行报告格式化、计算报告总数、用不同颜色在屏幕上显示字母等等。当
你识别出某些低层次功能后，再从事较高层设计可能会有把握些。
    以下是一些在进行自底向上合成时要牢记的原则：
•  问自己，关于系统要做什么你都知道哪些？
•  利用这一问题识别出某些低层次功能。

•  识别出这些低层次功能共同的方面，将其组合到一起。
•  向上一个层次，进行同样的工作，或回到顶端开始自顶向下。



其中自顶向下是从一般到特珠，自底向上是从特殊到一般。
自顶向下与自底向上
自底向上与自顶向下策略的首要区别是前者是合成，而后者则是分解。一个是从可控制的
零散问题出发，把它们合成到一起从而获得一个总体解决方案，而另一个则从总体问题出发，
将其分解成可控制的零散问题。两种方法各有优缺点。在实际使用时要详加比较。
自顶向下设计方法的特点是比较简单，人们往往擅长把大问题分解成小问题，而程序员们
则更是擅长这点。当一个问题是用层次结构模型化的时候，自上而下的分解方法恰好与其相符。
自顶向下设计的另一个优点是你可以避开实现细节。由于系统常常受到实现细节变动的干
扰（比如文件结构或报告格式的变化），因此把这些细节隐含在层级结构的底部，而不是让它在
顶部起支配作用，是非常有益的。
这种设计方法也有它的缺点。其中之一是系统的总体功能可能是很难识别的。关于系统所
作的最重要决定之一就是如何进行第一步分解工作，而在自上向下设计中，刚开始接触系统，
对其了解还很少时，便不得不做出这一决定，这是很危险的。它的另一个缺点是：由于许多系
统本身并不是层级结构的，因此是很难清晰地分解。或许这种设计方法的最大缺点就是它要求
系统在顶层要有一个单一而又清楚的功能，而对于现代事件驱动系统来说，这是很难想象的。
自底向上设计方法的优点是它在早期就可以识别出有用的功能子程序，结果是坚实可靠的
设计。如果已经开发了相似的系统，那么可以参阅一下旧系统，看看有什么可以借用的。
这种文件的弱点是很难单独地使用它。因为大多数人都不善于从小的概念出发形成综合         
的设想。这就像一个自己组装的玩具，我想我已经组装完了，怎么盒子中还有零件呢？好在，
你不必单独使用它。
它的另一个弱点是,有时从你识别出的细节出发，无法建造出整个程序，就像你无法用砖头
造出一架飞机一样。而且当你知道在底部需要什么功能时，你可能已经不得不进行顶层设计了。

不过，这两种方法并不是互相矛盾的。设计是一个启发的过程，就是说没有一种百试不爽
的设计方法，它总是一个尝试的过程。因此，在找到好方法之前，尽可以大胆尝试，可以用自
顶向下工作一会儿，再用自底向上工作一会儿。
设计也是一个逐次迭代逼近的过程。因此，你在第n 次用自底向上方法学到的东西，将在
第n＋l 次用自顶向下方法设计时起到很大帮助作用。
7.3    面向对象
面向对象设计方法的特点是通过对实际问题的分析，从中抽象出目标，然后再用程序语言
来表现它，其过程主要是：识别目标中的分目标并识别出对于分目标的操作，然后再根据分目
标的操作开发出一个系统。面向对象设计是在程序中设计目标或模块的一种方法。在较低的程
度上说，它也是设计单个子程序的一种方法。
    虽然有些鼓吹者把计算机历史划分为面向对象设计出现前阶段和面向对象设计出现后阶
段，但事实上面向对象设计与其它设计方法并不冲突。特别地，面向对象设计与结构化编程所
提供的低层次结构化并不是不兼容的，但它与高层次结构化的确不兼容。在更高的层次上，面
向对象设计方法在简单的功能性层次结构上，添加了类、群和非层次结构等新的概念。对这些
高层次的组合思想进行研究和标准化工作，将会使编程技术再向前产生一次飞跃。
在本书，对于面向对象设计的讨论是非常浅显的。与结构化设计方法相比，面向对象设计
的抽象化程度更高。本节着重论述的只是在较低层次上起作用的抽象方法，其中主要是在个别
语句、子程序和有限数量的子程序这个层次上的。这种设计方法相对来说也是一种新的设计理
论。它还没有完全成熟，关于这方面积累的设计经验也还不够丰富，但是，它是很有前途的。
7.3.1    关键思想
    面向对象设计是建立在如下主张之上的，即：一个程序模型越是真实地反映了实际问题，
那么，由此产生出的程序质量越好，在多数情况下，关于项目的数据定义要比功能稳定得多，
因此应象面向对象设计一样，根据数据来进行设计，这可以使设计更稳定。对于现代编程来说，
面向对象设计中有许多思想是很重要的。
抽象
    抽象所带来的主要好处是可以忽略掉无关紧要的细枝末节问题，而专注于重要的特性。绝
大多数现实世界中的目标都是抽象的，房屋是木材、钉子、玻璃、砖和水泥等的抽象，是把它
们组织起来的一种特殊形式。而木材本身，则又是纤维、细胞及某些矿物质的抽象，而细胞呢，
则又是各种各样的物质分子的抽象。
    在建造房屋时，如果你从分子层次上与木材、钉子等打交道，是永远不可能建成房屋的。
同样，在建造一个软件系统时，如果总是在相当于分子的层次上工作，那是不可能建成软件系
统的。在面向对象设计中，你尽力创造出与解决真实问题某一部分抽象程度相同的编程抽象，
以便解决编程问题中的类似部分，而不是用编程语言实体来解决问题。
面向对象设计擅长使用抽象，但因为它所使用的“智力砖块”，要比结构化设计中功能方
法所使用的“智力砖块”大得多。在结构化设计中，抽象的单位是函数；而在面向对象设计中，

抽象的单位是目标。由于目标包括函数及受函数影响的数据，从而使得在比函数更高层次上对
问题进行处理成为可能。这种抽象能力使你可以在更高层次上对问题进行考虑，而且，不必把
神经绷得太紧，就可以一次考虑很多问题。
封装
封装是对抽象不存在地方的补充。如果抽象对你说“你应该在较高层次上看一个目标”，而
封装则会说“你只能在这个层次上看一个目标”。这事实上就是6.2节所述的信息隐蔽的重复。
你对于一个模块所知道的只是它让你知道的那些，别的什么也没有。
我们继续用房屋比拟来说明问题：封装是一个使你可以看到房屋的外表但不能走进去的办
法，当然，或许你可以透过窗户看到一小部分内部情况。在较为过时的语言中，信息隐蔽完全
是自愿的行为，因为大门上没有“禁止入内”的标志，房门没有上锁，窗户也是敞开的，而对
于 Ada 语言来说，信息隐蔽则是强制性的：门被牢牢地锁上了，窗户紧闭，而且警报系统也在
工作，你所看到的就是你所得到的，而且是你得到的一切。
模块化
面向对象设计中的模块与结构化设计中模块的含义是一致的。相联系的数据和功能被放       
入模块，在理想情况下，模块是高度内聚而又松散耦合的。同信息隐蔽一样，当模块内部发生
变化时，其接口保持不变。
层次结构和继承性（ inheritance）
在设计软件系统时，你经常可以发现两个之间非常相似，其差别非常小的目标。例如，在
一个会计系统中，你可能既要考虑正式雇员，也要考虑兼职雇员，与两种雇员相联系的绝大多
数数据都是相同的，但也有一小部分是不同的。在面向目标编程中，你可以定义一种广义雇员，
把正式雇员当作一种广义雇员，但二者之间稍有差别。把兼职雇员也看作一种与种类无关的广
义雇员，那么这种操作就按广义雇员模式进行。如果某种操作是与雇员种类有关的，那么就按
雇员种类不同，分别进行操作。
定义这种目标间的共同和不同点称为“继承性”，因为兼职和正式雇员都从广义雇员那里继
承了许多特点。
    继承策略的好处是它与抽象的概念是一致的，抽象在不同层次的细节上与目标打交道。在
某一层次上调用某种分子；在下一个层次上调用纤维与植物细胞的组合，在最高层次上调用一
片木头。木头有某种特性（如你可以用锯子锯它或用斧头劈它），不管是松木还是加州红杉木，
它们有许多共同的特性，如同它们有不同特性一样。
    在面向对象编程中，继承性简化了编程，因为你只要写一个通用子程序来处理目标间的共
同特性，再编写几个专用子程序去处理它们间的不同特性就可以了。有些操作，例如Getsize()，
可能在任何抽象层次上都适用。程序语言支持Getsize()这种直到运行时才需要知道操作对象的
子程序特性称为“多形性”。像C++等面向对象的语言，自动支持继承性和多形性。而以目标为
基础的语言，如Ada和过程性语言如C 和Pascal则不支持这种特性。

目标与类
在面向对象设计中，最后一个关键概念是目标与类。目标是程序在运行时其中的任何一个
实体，而类则是当你看程序清单时存在的一个静态实体。目标是在程序运行时具有特定值和属
性的动态实体。例如，你可以定义一个具有名字、年龄、性别等属性的人，而在运行时则会遇
到Nancy，Tom 等人，也就是说，目标是类的特例，如果你对数据库术语很熟悉的话，它们的
区别与其中“模式”与“事例”的区别是类似的，在本节其余部分将不严格区分这些词，常会
把两种实体都称为“目标”。
7.3.2  面向对象设计的步骤
面向对象设计的步骤是：
•  识别目标及其属性，它往往是数据。
•  确定对每个目标可以做些什么。
•  确定每一个目标可以对其它目标做些什么。
•  确定每个目标对其它目标来说是可见的部分——哪一部分是开放的，哪一部分是专用
的。
•  确定每个目标的公共接口。
这些步骤下一定非要按某一特定顺序来进行，但是却需要重复。逐次迭代逼近对面向对象
设计是与其它设计方法同样重要的，下面将分别论述这些步骤。
识别目标及其属性。计算机程序通常是以客观世界实体为基础的，例如，你可以用客观世
界中的雇员，时间卡及帐单为基础来建造一个时间——记帐系统。图7-3 中表示了从面向对象
观点来看，这一系统的表现形式。
在图形系统中的目标将包括：窗口、对话框、按钮、字体、绘图工具等。对问题域进行进
一步研究，可能会发现比这种一对一方式更好的软件目标识别方法，但是，从客观世界中的真
实目标出发总是一个比较好的方法。
识别目标属性并不比识别目标困难。每一个目标都有与计算机程序相关联的特性。例如，
在时间——记账系统中，一雇员目标将具有姓名、标题和记账率；顾客目标将有姓名、支票地
址、收支状况及存款余额等；账单目标具有欠账数量、顾客姓名、日期等等。
图中目标的图形符号与第六章讲述的模块符号类似。
确定可以对一个目标做些什么。对每一个目标都可以进行一系列操作，在时间——记账系
统中，雇员的记账率等可以变动，可以要求提供雇员的奖励情况等，顾客目标可以更改其存款
额或地址等。
确定目标之间可以互相做些什么。这一步骤与其字面意义是相似的。在时间——记账系统
中，雇员可以对其它目标做些什么呢？做不了什么。雇员所能做的一切便是输入时间卡信息。
而账单则可以接受时间卡信息，在更复杂的系统中，其它相互作用更为明显。
确定每一个目标中对其它目标来说是可见的部分。在设计中的一个关键问题就是决定目标
的哪些部分应该是可见的，哪些部分应该是隐蔽的。对于数据和功能来说，都要做出这种确定。
在表示时间——记账系统的图7-2 中只表示出了可见的部分，隐蔽的部分则被藏在黑

盒子中。顾客与雇员目标看起来是非常复杂的，因为它们每一个都具有七八个可见的特性。这
种复杂的表现形式是图示法的一个弱点，这种情况会随着可见特性的增加而恶化。而一个精心
设计好的目标往往有许多附加的可见特性。
定义每一个目标的接口。在设计目标中的最后一个步骤是为每个目标定义一个正式的、语
法的、在程序层次上的接口。这包括由目标提供的功能和目标与类之间的继承关系。特别地，
这一步将包括函数和子程序说明。例如：时间卡的接口（用C++编写）可能是这样的：
class TimeCard
{
public:
int Enter
(
EMPLOYEE_ID Employee,
DATE Date,
CLIENT_ID Client,
PROJECT ProjectCode,
int Hours
)；

int Retrieve
(
int& Hours,
DATE& Date,
CLIENT_ID& Client,
PROJECT ProjectCode,
EMPLOYEE_ID Employee
);
protected:
…
};
当你进行完这一步的工作，到达高层次的面向对象系统组织时，可以用两种方法进行迭代，
以便得到更好的目标——类组织。你也可以对定义的每一个目标进行迭代，把设计推向更详细
的层次。
7.3.3  典型面向对象设计的评论
一个面向对象系统通常有至少四类目标。如果你不知道这其中每类目标的一些情况，你很
可能会漏掉某类目标。
•  问题域要素。这个要素直接指向问题域，在前述的记账系统中，问题域包括客观世界中
的目标，如：雇员、顾客，时间卡和账单等。
•  用户接口要素。这个要素指的是系统中负责人机交互的部分。它包括数据入口类型、窗
口、对话框、按扭等等。正如6.2 节中提到的那样，最好把系统的用户接口部分隐蔽
起来以适应修改。
•  任务管理要素。这类要素指的是计算机本身的目标。包括实时任务管理程序、硬件接口、
通讯协议等。
•  数据管理要素。这部分要素包括保持一致的数据。它包括数据库以及其相联系的所有存
储、维护和检索等功能。
7.4  对目前流行设计方法的评论
如果你仔细观察日前流行的设计方法——包括结构化设计和面向对象设计——你会发现每
种方法都包括两个主要部分：
•  把一个系统分解成子系统的准则
•  解释分解的图形式语言符号
•  有些方法还包括第三个要素
•  防止你使用其它方法的规定
把“设计”的意义限制在前两个要素上说明设计的核心是把系统分解成亚程序
( Subprogram ) ，同时也说明亚程序的设计并不具备足够的挑战性，不值得讨论。

一个好的系统分解的确是很有价值的，但并不是说一旦确立了好的结构，设计就可以停止
了。在确认出子程序的模块之后，还有许多设计工作要做。
伴随着某些设计方法的第三个要素，即强调应该只使用一种方法的思想，是非常有害的。
没有一种方法囊括了设计系统所需的全部创造力和洞察力。强调使用一种方法将破坏设计中的
思维过程。
    但是，设计方法的选择往往会成为一种宗教似的问题——你去参加了一个宗教复兴会议，
听一些结构化设计的先知讲道，然后你回到自己的圣地在石碑上写下一些神圣的程序，从此以
后，你不再允许自己进入非基督教的领域。你应该知道，软件工程不是宗教，不应该引人宗教
的狂想性。
如果你是个建筑工人，你不会用同样的方法建造每一幢建筑物。在周一你在浇注水泥，而
到了周末你则在修建一幢木屋。你不会用水泥来修木屋，也不会在一幢新建好的摩天大楼门口
挂上“成人禁止入内”的牌子。你会根据不同的建筑物而采取不同的施工方法，从建造房子中，
你应该得到关于编程方法选择的启示，应该选择与问题相适应的方法，这种世俗方法的合理性
已经被许多例子和研究所证明。每种方法都有其优点，但同时也有其弱点，应分析使用(Peter
和Tripp 1977，Mannino 1987，Kelly 1987，Loy 1990)。
但是，有些方法的障碍是由它们自己的复杂的术语产生的。比如，你想学习结构化设计，
你必须懂得如下词汇：输入流与模块、输出流与模块、正规、控制、公用、全局和内容耦合、
功能的、顺序的、通讯的、过程的、临时的、逻辑的和偶然性内聚。输入、输出、事务处理中
心、事物处理分析和事物处理模块，甚至Benuzerfreundlichkeit（多可怕！）一词也出现了。字
典也无法给出这些词的解释。
    结构化设计，以隐蔽信息为目标的设计和面向对象设计等方法提供了看问题的不同角度。
图7-4 给出了使用它们的典型方法。
    从事结构化设计的人与从事面向对象设计的人会发现他们进行交流非常困难，原因是他们
没有意识到是在不同层次上讨论设计的，因此主题也是不同的。从事结构化设计的Tom说：“我
想这个系统应该分解成50个子程序。”面向对象设计的Joh则说：“我认为系统应划分成7个目
标”。如果你仔细观察，可能会发现这7 个目标中可能共含有50 个子程序，而Tom的子程序或
许可以分成7 组。
7.4.1  何时使用结构化设计
结构化设计主要是一种把程序分解成子程序的方法。它强调功能但不强调数据。一个面向
功能的问题域的例子是一个以批处理方式读入数据，按照可以预计的顺序对数据进行可以预计
的处理并且写数据。
结构化设计并没有把子程序组成一个协同工作子程序组的概念，也没有子程序内部设计的
概念，除非这个子程序的内部会影响到整个系统。因此，结构化设计非常适用于具有许多互不
作用的独立功能的系统。同时，它也适于那些只有几百行代码的小型程序，因为这些程序过于
简单，没有建立类、目标和属性的必要。
结构化设计的最先提出者Larry Constantine，曾经发表过一篇“目标、函数和程序可扩展性”
的文章，论述了把结构化设计和面向对象设计组合到一起的设计方法。如果数据变动可能性很
大，那么采用面向对象设计比较合适，因为它将变动可能性较大的数据独立在目标（模块）

中。如果功能变动的可能性较大，采用面向对象设计就不太适合了。因为功能散布在许多目标
（模块）中。如果功能变化的可能性比数据要大，那最好采用分解功能的结构化设计。
7.4.2  何时采用信息隐蔽
无论什么问题领域，都应该尽量采用信息隐蔽。使用它没有任何危险。到目前为止，联邦
卫生委员会还没有发现它会发生危险，不论是设计子程序、模块，还是目标程序，它都是很有
效的，因此你尽可以放心使用它。
7.4.3  何时采用面向对象设计
面向对象设计与结构化设计的主要区别是：面向对象设计在较高抽象层次上要比结构化设

计有效。这是具有重大历史意义的。因为结构化最初开发起来时程序员们正在建立定义大而复
杂的系统，到现在已经远不及如今的大规模系统那样复杂了。
面向对象设计主要是设计模块数据和对数据操作的集合。它非常适于从最顶层分解系统。
而当你识别出目标的接口并开始编码时，你往往会转向结构化设计。如果你用面向对象的语言
编程，那么很难认为你没有在面向对象设计，因为你用面向对象方法、信息或其它进行结构设
计工作。如果你是在用比较传统的过程性语言进行设计，则很容易认为你是在用较旧的结构化
设计方法，在这时，使用这一方法是很合适的。
面向对象设计适合于任何客观世界中的目标。这类系统的例子包括高度交互化的窗口、对
话框、按钮等程序；面向对象的数据库；需要对随机事件做出反应的事件驱动系统等等。
关于面向对象设计技术的研究工作主要是针对代码在105～1005 行以上的系统的。对于这
种规模的系统，结构化设计基本上是无能为力的，而面向对象设计则往往比较有效。然而，除
了这些超大型项目之外，稍显陈旧的结构化设计还是比较有效的，而面向对象设计对于较小型
项目的有效性，却还有等待证明。
7.5  往返设计
通过组合使用主要设计方法来扬长避短是完全可能的。每种设计方法都只是程序员工具箱
中的一件工具，不同的工具适合不同的工作，你将从研究所有方法的启发中获益无穷。
下面一小节结论述了软件设计为什么困难的某些原因，并指出了如何组合使用结构化设计，
面向对象设计和其它设计方法。
7.5.1  什么是往返
你可能会有这样的体验：当你编写程序快结束时，你非常希望能有机会再重新编写一次，
因为在编写过程中你对问题又有了更深的理解。这对设计也是同样适用的，只不过在设计中这
个循环的周期更短，带来的好处也更大，因此，你完全可以在设计过程中进行几次往返。
“往返设计”一词抓住了设计是个迭代过程这一特点：通常你不会只从A点走到B 点，往
往还需要再返回A 点。
在用不同的设计方法对各种设计方案进行尝试的进程中，将从高层次的总体上和低层次的
细节上对问题进行观察。在从事高层次问题时获得的总体印象将会对你在低层次细节中的工作
有很大帮助；同时，在从事低层次问题时所获得的细节将为你对高层次的总体理解和作出总体
设计决定奠定下良好的基础。这种在高层次和低层次之间往返思维过程是非常有益的，由此而
产生的结构，将比单纯自顶向下或自底向上产生的结构要稳定得多。
许多程序员，都会在这一往返过程中遇到麻烦。从对系统的一个观察点转到另一个观察点
上，的确是很困难的，但这是进行有效设计所必需的，你可以阅读一下Adams 于1980 年写的
一本叫“Conceptual Blockbusting”的书，来提高自己思维的灵活性。
7.5.2    设计是一个复杂的过程
  J.P Morgon曾经说过人们在做事情时常常有两个原因：表面上冠冕堂皇的原因和真正的
原因。在设计中，最终结果往往看起来是井井有条的，似乎设计者从未犯过任何设计错误，事