不过，这两种方法并不是互相矛盾的。设计是一个启发的过程，就是说没有一种百试不爽
的设计方法，它总是一个尝试的过程。因此，在找到好方法之前，尽可以大胆尝试，可以用自
顶向下工作一会儿，再用自底向上工作一会儿。
设计也是一个逐次迭代逼近的过程。因此，你在第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曾经说过人们在做事情时常常有两个原因：表面上冠冕堂皇的原因和真正的
原因。在设计中，最终结果往往看起来是井井有条的，似乎设计者从未犯过任何设计错误，事

实上，设计过程很少有像最终结果那样井井有条。
设计是一个复杂的过程。因为你很难把正确答案与错误答案区分开来。如果你让三个人分
别设计同一个程序，他们带回来的往往是三个大相径庭的方案，而且其中每一个看起来都非常
适用。它是一个复杂的过程还因为你在设计过程中曾钻过许多死胡同、犯过许多错误。说它是
一个复杂的过程也是因为你不知道什么时候设计方案已经足够完善了。什么时候算完成呢？对
这个问题的通常答案是“当你没有时间时”。
7.5.3  设计是一个“险恶”的过程
Horst Rittel和 Melvin Webber 把“烦人”的问题，定义成只有通过解决它或者部分解决它，
才能给出明确定义的问题。这个似是而非的定义事实上暗示着你不得不首先“解决”这个问题，
对其有一个清楚的定义和理解，然后再重新解决一遍，以获得正确的解决办法。这一过程对软
件开发就像母爱和面包对你我一样必不可少。
在现实中，关于险恶问题的一个富于戏剧性的例子便是托卡马大桥的设计。在修建大桥时，
主要考虑的便是它应该能承受设计载荷并能抗12级大风。然而，没人想到风在吹过桥时会产生
“卡门旋涡”——一种特殊的空气动力学现象，从而使桥产生横向简谐振动。结果，在1940 年
的一天，只在7 级风的作用下，桥便因振动而坍塌了。
说它是险恶问题的典型例子是因为直到桥坍塌时，也没有一个设计师想到应该在这个设计
中考虑空气动力学问题。只有在建成大桥（解决问题）之后，才使得他们意识到了要考虑的这
一“额外”问题，经过重新设计，新桥至今依然屹立在河上。
你在学校中设计的程序和在实际工作中设计的程序最重要的不同是：在学校中遇到的程序
设计问题，几乎没有哪个是险恶的，教师留给你的程序作业都是预先想好让你一次即可完成的。
如果哪位教师留给你们一个程序作业，当你们完成后他又突然改变了作业题目，接着，当你即
将完成那个程序时，他又改变了主意，会怎么样呢？我想，如果有谁胆敢这样的话，你们肯定
会把它绞死。但在实际工作中，几乎总是这样。
7.5.4  设计是一个启发的过程
进行有效设计的关键是要认识到它是个启发的过程。设计中，总是吃一堑，长一智的。往
返设计的概念事实上解释了设计是个启发过程这一事实，因为你要把任何设计方法都只当成一
种工具。一种工具只对一种工作或者一种工作的某一部分才有效，其余的工具适合其它的工作，
没有一种工具是万能的。因此，你往往要同时使用几种工具。
一种很有效的启发工具就是硬算。不要低估它。一个有效的硬算解决方案总比优雅却不能
解决问题的方案要好。以搜索算法的开发为例，虽然在1946年就产生了对分算法的概念，但直
到16 年后，才有人找到了可以正确搜索各种规模的表的算法。
图示法是另一种有力的启发工具。一幅图抵得上一千个单词。你往往不愿用那一千个单词
而宁愿用一幅图，因为图形提供了比文字更高的抽象水平，有时或许你想在细节上处理某一问
题，但是，更常见的是在总体上处理问题。
往返设计的一个附加的启发能力是你在设计的头几次循环中，可以暂时对没有解决的细节
问题弃之不管，你不必一次就对一切都做出决定，应记住还有一个问题有待做出决定，但同时
要意识到，你目前还没有充分的信息来解决这个问题。为什么在设计工作的最后10%的部分苦

苦挣扎呢？往往在下一循环中它们会自然获得解决。为什么非要在经验和信息都不足的情况下
草率决定呢？你完全可以在以后等经验和信息丰富时做出正确决定。有些人对一次设计没能彻
底解决问题会感到很不舒服，但与其很不成熟地勉强解决问题，不如把问题暂放一个，待到信
息足够丰富时，再解决它。
最重要的设计原则之一是不要死抱着一种方法不放。如果编写PDL无效的话，那么就作图，
或用自然语言写出来，要么就写一小段验证程序，或者使用一种完全不同的方法，比如硬算解
决法，坚持用铅笔不停地写和画，大脑或许会跟上。如果这一切都无效，暂时放开这个问题。
出去自由自在地散散步，或者想一下别的，然后再回到这个问题上。如果你已经尽了全力但还
是一无所获，那么暂时不考虑这个问题往往会比坚持冥思苦想更快得到答案。最后，可以借鉴
其它领域中的方法来解决软件设计中的问题。关于问题解决中的启发方法的最初的一本专著是
G. Polya 的《How To solve in》一书（1957），Polya的书推广了数学中解决问题的方法，表 7-1
就是对其所用方法的总结，本表摘自Polya 的书中的类似的总结表：
表7-1  怎样解决问题

l．理解问题，你必须理解要解决的问题
问题是什么？条件是什么？数据是什么？有可能满足条件吗？已知条件足以确定未知
吗？已知条件是否不够充分？是否矛盾7 是否冗余？
画一个图，引入恰当的符号，把条件的不同部分分解开。
2．设计一个方案。找到已知数据和未知之间的联系。如果不能找出直接联系的话，你可能不得
不考虑一些辅助问题，但最后，你应该找到一个解决方案。
以前你是否遇到过这个问题？或者是见过与它稍有不同的问题？是否知道与其相关的问
题？是否知道在这个问题中有用的定理？
看着未知！努力回忆起一个有着相同或类似未知的问题。这里有一个与此相关的你以前
解决过的问题，你能利用它吗？是能利用它的结论还是能用它的方法？是否该引入辅助
要素以使这个问题可以再用？
能否重新表述一下问题？能用另外一种方式表述它吗？返回到定义。
如果你无法解决这个问题,可以先试着解决一些别的问题,是否能想象出一个容易解决的
相关问题；一个广义些的问题或是一个更特殊的问题？一个相似的问题呢？能否解决问
题的一部分呢？仅保留一部分条件,忽略其余条件；未知可以被决定到什么程度？会发生
什么变化？能否从数据中推导出一些有用的东西？能否找出适于确定未知的其余数据？
能否改变数据或未知？同时改变两者呢？这样做能否使新的未知和新的数据更接近些？
是否使用了全部的数据？使用全部条件了吗？是否考虑了这个问题的全部必要条件？
3．执行你的计划。
执行你解决问题的计划，同时检查每一步工作。你是否可以认定每一步都是正确的？你
能证明这点吗？
4．回顾，检查一下答案。
你能检查一下答案吗？能检查一个论证吗？能否用另外一种方法推导出答案？能否一眼
就看出答案？
能否在其它问题中再利用本题的答案或者结论？
7.5.5  受迎的设计特点
高质量的设计往往有一些共同的特点。如果你能达到这些目标，那么可以认为你的设计也
是非常成功的。有些目标是互相矛盾的。但是这是设计的挑战所在，在相互矛盾的目标之间做