软件构建中的设计.doc

775.1 Key Design Concepts5Design in Construction第 5 章软件构建中的设计/0578内容 5.1 设计中的挑战：第74页 5.2 关键的设计概念：第77页 5.3 设计构造块：启发式方法：第87页 5.4 设计实践：第110页 5.5 对流行的设计方法的评论：第118页相关章节 软件架构：第3.5节 能够工作的类：第6章 高质量的子程序：第7章 防御式编程：第8章 重构：第24章 程序规模会如何影响构建：第27章或许有人会认为设计并不是软件构建中的一个活动。然而在小型项目里，有很多活动都算作构建活动，其中也常常包含了设计。在一些更大的项目里，正规的架构可能只是解决了系统级的事项，而特意把大部分的设计工作留到构建阶段去做。在另外一些大型项目中，设计可能会详细到能够让编码工作近乎机械化，但很少有如此完整的设计程序员通常也要对部分程序进行设计，也许是正式的，也许不是。交叉参考 有关大型项目和小型项目中所要求的不同层次的正规性，请详见第27章“程序规模会如何影响构建”。在小型的、非正式的项目里，很多的设计工作是程序员坐在键盘前完成的。这里的“设计”可能就是指在编写具体代码之前先用伪代码写出一个类的接口，也可能就是在编码之前画出几个类之间的关系图，还可能就是询问另一位程序员用哪个设计模式会更好。无论是以何种方式来进行设计，小型项目也能和大型项目一样从精心的设计之中获益，而如果能认识到设计是一项明确的活动，你就更会获益匪浅。设计是个庞大的话题，而这一章只能涵盖其中的少数侧面。一个好的类或子程序的设计在很大程度上是由系统的架构所决定的，因此，请确保第3.5节中所论述过的架构先决条件已经满足。更多的设计工作是在个别的类和子程序这个层次上完成的，第6章“可以工作的类”，以及第7章“高质量的子程序”中会分别予以介绍。5.1如果你对软件设计方面的话题已经很熟悉，可以只看这些重点部分第5.1节关于设计中的挑战，以及第5.3节中关键的启发式方法。Design Challenges设计中的挑战交叉参考 关于启发式过程和确定性过程的差别，请参见第2章“用隐喻来更充分地理解软件开发”。“软件设计”一词意味着去构思、创造或发明一套方案，把一份计算机软件的规格说明书要求转变为可实际运行的软件。设计就是把需求分析和编码调试连在一起的活动。好的高层次设计能提供一个可以稳妥容纳多个较低层次设计的结构。好的设计对于小型项目非常有用，对于大型项目就更是不可或缺。设计也会面临大量的挑战，这正是本节将要概述的内容。Design Is a Wicked Problem设计是一个险恶的问题希望软件设计师用一种理性的、不会犯错的方式从需求说明中推导出设计，这一画面根本就不现实。没有哪个系统是用这种方式设计出来的，以后也不可能有。即便是教科书和论文中的小型程序开发也是不真实的。它们都是经过修订和修饰的，直到作者让我们看到他想要做到的结果，因而是不可能在实际中发生的过程。David Parnas and Paul Clements根据Horst Rittel和Melvin Webber的定义，“险恶的（wicked）”问题就是那种只有通过解决或部分解决才能被明确的问题（1973）。这个看似矛盾的定义其实是在暗示说，你必须首先把这个问题“解决”一遍以便能够明确地定义它，然后再次解决该问题，从而形成一个可行的方案。这一过程已经如影随形地在软件开发中存在数十年了（Peters and Tripp 1976）。在我所了解的世界中，最引人注目的一个关于这类险恶问题的例子，就是原来Tacoma Narrows大桥的设计问题了。在建这座大桥的那个时期，设计一座桥梁时考虑的主要问题就是它是否足够结实以承受设计负荷。然而对于Tacoma Narrows这座桥而言，大风给它带来了出乎意料的横向谐波。在1940年狂风大作的某一天，这种谐波越来越大且不可控制，从而让大桥最终坍塌，如图5-1所示。这是一个险恶问题的好例子，因为直到这座桥坍塌，工程师们才知道应该充分地考虑空气动力学的因素。只有通过建造这座大桥（即解决这个问题），他们才能学会这一问题中应该额外考虑的环节，从而才能建造出到现在依然矗立不倒的另一座桥梁。图5-1 Tacoma Narrows大桥一个险恶问题的实例你在学校中所开发的程序和你在职业生涯中所开发的程序的主要差异就在于，学校里的程序所解决的设计问题很少（如果有的话）是险恶的。学校里给你的编程作业都是为了让你能从头到尾直线前进而设计的。如果有位老师给你一份编程作业，你刚完成设计时他就把作业的要求改了，然后就在你将要提交完整的程序时，他又对作业的要求再次改动，这时你肯定会十分生气。然而这一过程正是在专业编程中每日可见的真实情形。Design Is a Sloppy Process (Even If it Produces a Tidy Result)设计是个了无章法的过程（即使它能得出清爽的成果）深入阅读 关于这一观点的更完整的解释，请参阅“一种理性的设计过程：如何/为和要仿制它”（A Rational Design Process: How and Why to Fake it, Parnas and Clements 1986）。软件设计的成果应该是组织良好、干净利落的，然而形成这个设计的过程却并非如此清爽。说设计了无章法，是因为在此过程中你会采取很多错误的步骤，多次误入歧途你会犯很多的错误。事实上，犯错正是设计的关键所在在设计阶段犯错并加以改正，其代价要比在编码后才发现同样的错误并彻底修改低得多。说设计了无章法，还因为优、劣设计之间的差异往往非常微妙。另外，说设计了无章法，还因为你很难判断设计何时算是“足够好”了。设计到什么细节才算够？有多少设计需要用形式化的设计符号完成，又有多少设计可以留到编码时再做？什么时候才算完成？因为设计永无止境，因此对上述问题最常见的回答是“到你没时间再做了为止”。交叉参考 关于这一问题的更好答案，请参见本章后面第5.4节“要做多少设计才够？”Design Is About Tradeoffs and Priorities设计就是确定取舍和调整顺序的过程在一个理想的世界中，每一套系统都能即刻完成运行，不消耗任何存储空间，不占用任何网络带宽，没有任何错误，也无须任何成本即可生成。而在现实世界里，设计者工作的一个关键内容便是去衡量彼此冲突的各项设计特性，并尽力在其中寻求平衡。如果快速的反应速度比缩减开发时间更重要，那么设计者会选取一套设计方案。而如果缩减开发时间更重要，那么好的设计者又要巧妙地形成另一套不同的设计方案。Design Involves Restrictions设计受到诸多限制设计的要点，一部分是在创造可能发生的事情，而另一部分又是在限制可能发生的事情。如果人们在建造房屋时拥有无限的时间、资源和空间，那么你会看到房屋不可思议地随意蔓延，每幢楼都有上百间屋子，一只鞋子就可以占用一间屋子。如果毫无约束，软件最后也会是这样的结果。正是由于建造房屋时有限资源的限制，才会促使产生简单的方案，并最终改善这一解决方案。软件设计的目标也如此。Design Is Nondeterministic设计是不确定的如果你让三个人去设计一套同样的程序，他们很可能会做出三套截然不同的设计，而每套设计都很不错。剥猫的皮可能有不止一种方法，但设计计算机程序却通常有数十种方法。Design Is a Heuristic Process设计是一个启发式过程正因为设计过程充满了不确定性，因此设计技术也就趋于具有探索性“经验法则”或者“试试没准能行的办法”而不是保证能产生预期结果的可重复的过程。设计过程中总会有试验和犯错误。在一件工作或一件工作的某个方面十分奏效的设计工具或技术，不一定在下一个项目中适用。没有任何工具是用之四海而皆灵的。Design Is Emergent设计是自然而然形成的/0539把设计的这些特性综合归纳起来，我们可以说设计是“自然而然形成的”。设计不是在谁的头脑中直接跳出来的。它是在不断的设计评估、非正式讨论、写试代码大全（第2版）875.2 关键的设计概念验代码以及修改试验代码中演化和完善的。深入阅读 软件并非是唯一会随时间变化而变化的结构。物理结构也会演变参阅How Buildings Learn (Brand 1995)。5.2几乎所有的系统都在其开发的起始阶段经历过某种程度的设计变更，而当它们进入后续版本后通常都会进行更大的改变。软件的性质决定了这些改变在多大程度上是有益且可被接受的。Key Design Concepts关键的设计概念好的设计源于对一小批关键设计概念的理解。这一节将会讨论“复杂度”所扮演的角色、设计应具有的特征，以及设计的层次。Softwares Primary Technical Imperative: Managing Complexity软件的首要技术任务：管理复杂度交叉参考 关于复杂度除了设计之外还会影响到的编程事宜，请参见第34.1节“克服复杂性”。为了理解管理复杂度的重要性，我们有必要引用Fred Brooks的那篇具有里程碑意义的文章没有银弹：软件工程中本质性和偶然性Accidental and Essential Difficulties偶然的难题和本质的难题Brooks认为，两类不同的问题导致软件开发变得困难本质的问题和偶然的问题。关于这两个术语，Brooks引用了亚里士多德时代的一个哲学传统。在哲学界，本质的（essential）属性是一件事物必须具备、如果不具备就不再是该事物的属性。汽车必须具有引擎、轮子和车门，不然就不能称其为汽车。如果不具备这其中任何一个本质的属性，它就不再是一辆汽车。偶然的（accidental）属性则是指一件事物碰巧具有的属性，有没有这些属性都并不影响这件事物本身。一辆汽车可能有台V8发动机，或是涡轮增压四缸发动机，或其他什么种类的发动机，无论这些细节如何，它总是一辆汽车。一辆汽车也可能是两门或四门的；它可能有粗劣或豪华的轮毂。所有这些细节都是次要的偶然属性。你也可以把偶然属性想成是附属的、任意的、非必要的或偶然出现的性质。交叉参考 偶然性难题在开发的初期比开发的晚期更突出。更多内容请参见第4.3节“你在技术浪潮中的位置”。Brooks观察到，软件开发中大部分的偶然性难题在很久以前就已得到解决了。比如说，与笨拙的语法相关的那些偶然性难题大多已在从汇编语言到第三代编程语言的演进过程中被解决了，而且这类问题的重要性也渐渐下降了。与非交互式计算机相关的偶然性难题也随着分时（time-share）操作系统取代批模式（batch-mode）系统而被解决。集成编程环境更是进一步解决了由于开发工具之间无法很好地协作而带来的效率问题。Brooks论述说，在软件开发剩下的那些本质性困难上的进展将会变得相对缓慢。究其原因，是因为从本质上说软件开发就是不断地去发掘错综复杂、相互连接的整套概念的所有细节。其本质性的困难来自很多方面：必须去面对复杂、无序的现实世界；精确而完整地识别出各种依赖关系与例外情况；设计出完全正确而不是大致正确的解决方案；诸如此类。即使我们能发明出一种与现实中亟待解决的问题有着相同术语的编程语言，但是人们要想清楚地认清现实世界到底如何运作仍有很多挑战，因此编程仍会十分困难。当软件要解决更大规模的现实问题时，现实的实体（entities）之间的交互行为就变得更为复杂，这些转而又增加软件解决方案的本质性困难。所有这些本质性困难的根源都在于复杂性不论是本质的，还是偶然的。Importance of Managing Complexity有两种设计软件的方式：一种方法是让设计非常简单，看上去明显没有缺陷；另一种方法是让设计非常复杂，看上去没有明显的缺陷。C. A. R Hoare管理复杂度的重要性在对导致软件项目失败的原因进行调查时，人们很少把技术原因归为项目失败的首要因素。项目的失败大多数都是由差强人意的需求、规划和管理所导致的。但是，当项目确由技术因素导致失败时，其原因通常就是失控的复杂度。有关的软件变得极端复杂，让人无法知道它究竟是做什么的。当没人知道对一处代码的改动会对其他代码带来什么影响时，项目也就快停止进展了。管理复杂度是软件开发中最为重要的技术话题。在我看来，软件的首要技术任务便是管理复杂度，它实在是太重要了。复杂度并不是软件开发中的什么新特征。计算机先驱Edsger Dijkstra指出，计算是唯一的一种职业，在其中，人的思维需要从一个字节大幅跨越到几百兆字节跨越比例为109分之1，也就是九个数量级 (Dijkstra 1989)。这一比例大得惊人。Dijkstra是这样描述的：“在语义的层次量上相比，一般的数学理论几乎是平坦的。由于提出了对很深的概念层次的需要，自动化的计算机使我们面临着一种本质上全新的智力挑战，是史无前例的挑战。”当然，从1989年以来软件变得更为复杂了，Dijkstra所说的1比109的比例今天很可能已经变成了1比1015。Dijkstra还指出，没有谁的大脑能容得下一个现代的计算机程序（Dijkstra 1972），也就是说，作为软件开发人员，我们不应该试着在同一时间把整个程序都塞进自己的大脑，而应该试着以某种方式去组织程序，以便能够在一个时刻可以专注于一个特定的部分。这么做的目的是尽量减少在任一时间所要考虑的程序量。你可以把它想做是一种心理上的杂耍（边抛边接：通过轮流抛接使两个或两个以上物体同时保持于空中）程序要求你在空中保持的（精神上的）球越多，你就越可能漏掉其中的某一个，从而导致设计或编码的错误。在软件架构的层次上，可以通过把整个系统分解为多个子系统来降低问题的复杂度。人类更易于理解许多项简单的信息，而不是一项复杂的信息。所有软件设计技术的目标都是把复杂问题分解成简单的部分。子系统间的相互依赖越少，你就越容易在同一时间里专注问题的一小部分。精心设计的对象关系使关注点相互分离，从而使你能在每个时刻只专注于一件事情。在更高汇聚的层次上，包（packages）提供了相同的好处。你已陷入复杂度的沼泽的一个现象就是，你发现自己顽固地用一种明显毫无作用的方法至少在任何外人眼里。这就像是一个遇到车子抛锚的蠢货一样他把水放到电池里然后把烟灰缸倒掉。P. J. Plauger保持子程序的短小精悍也能帮助你减少思考的负担。从问题的领域着手，而不是从底层实现细节入手去编写程序，在最抽象的层次上工作，也能减少人的脑力负担。受着人类固有限制影响的程序员的底线，就是要写出既让自己容易理解，也能让别人容易看懂，而且很少有错误的程序代码。How to Attack Complexity如何应对复杂度高代价、低效率的设计源于下面三种根源： 用复杂的方法解决简单的问题 用简单但错误的方法解决复杂的问题 用不恰当的复杂方法解决复杂的问题正如Dijkstra所指出的，现代的软件本身就很复杂，无论你多努力，最终都会与存于现实世界问题本身的某种程度的复杂性不期而遇。这就意味着要用下面这两种方法来管理复杂度： 把任何人在同一时间需要处理的本质（essential）复杂度的量减到最少 不要让偶然性（accidental）的复杂度无谓地快速增长一旦你能理解软件开发中任何其他技术目标都不如管理复杂度重要时，众多设计上的考虑就都变得直截了当了。Desirable Characteristics of a Design当我解决问题的时候，我从来不考虑美感。我只想着如何才能解决它。但一旦解决了问题，如果解决方法不够优美的话，我就知道做错了。R. Buckminster Fuller理想的设计特征高质量的设计具有很多常见的特征。如果你能实现所有这些目标，你的设计就真的非常好了。这些目标之间有时会相互抵触，但这也正是设计中的挑战所在在一系列相互竞争的目标之中做出一套最好的折中方案。有些高质量设计的特征也同样是高质量程序的特征，如可靠性和性能等。而有些则只是设计范畴内的特征。交叉参考 这些特征都是和软件质量的基本特性相关的。关于这些基本特性的更多内容，请参见第20.1节 “软件质量的特性”。下面就列出一些设计范畴内的特征：最小的复杂度 正如刚刚说过的，设计的首要目标就是要让复杂度最小。要避免做出“聪明的”设计，因为“聪明的”设计常常都是难以理解的。应该做出“简单”且“易于理解”的设计。如果你的设计方案不能让你在专注于程序的一部分时安心地忽视其他部分的话，这一设计就没有什么作用了。易于维护 易于维护意味着在设计时为做维护工作的程序员着想。请时刻想着这些维护程序员可能会就你写的代码而提出的问题。把这些程序员当成你的听众，进而设计出能自明的（self-explanatory）系统来。松散耦合 松散耦合（loose coupling）意味着在设计时让程序的各个组成部分之间关联最小。通过应用类接口中的合理抽象、封装性及信息隐藏等原则，设计出相互关联尽可能最少的类。减少关联也就减少了集成、测试与维护时的工作量。可扩展性 可扩展性（extensibility）是说你能增强系统的功能而无须破坏其底层结构。你可以改动系统的某一部分而不会影响到其他部分。越是可能发生的改动，越不会给系统造成什么破坏。可重用性 可重用性（reusability）意味着所设计的系统的组成部分能在其他系统中重复使用。高扇入 高扇入（high fan-in）就是说让大量的类使用某个给定的类。这意味着设计出的系统很好地利用了在较低层次上的工具类（utility classes）。低扇出 低扇出（low fan-out）就是说让一个类里少量或适中地使用其他的类。高扇出（超过约7个）说明一个类使用了大量其他的类，因此可能变得过于复杂。研究发现，无论考虑某个子程序调用其他子程序的量，还是考虑某个类使用其他类的量，低扇出的原则都是有益的（Card and Glass 1990; Basili, Briand, and Melo 1996）。可移植性 可移植性（portability）是说应该这样设计系统，使它能很方便地移植到其他环境中。 精简性 精简性（leanness）意味着设计出的系统没有多余的部分（Wirth 1995, McConnell 1997）。伏尔泰曾说，一本书的完成，不在它不能再加入任何内容的时候，而在不能再删去任何内容的时候。在软件领域中，这一观点就更正确，因为任何多余的代码也需要开发、复审和测试，并且当修改了其他代码之后还要重新考虑它们。软件的后续版本也要和这些多余代码保持向后兼容。要问这个关键的问题：“这虽然简单，但把它加进来之后会损害什么呢？”层次性 层次性（stratification）意味着尽量保持系统各个分解层的层次性，使你能在任意的层面上观察系统，并得到某种具有一致性的看法。设计出来的系统应该能在任意层次上观查而不需要进入其他层次。交叉参考 关于在旧有系统上进行工作的更多内容，请参见第24.5节“重构策略”。举例来说，假设你正在编写一个新系统，其中用到很多设计不佳的旧代码，这时你就应该为新系统编写一个负责同旧代码交互的层。在设计这一层时，要让它能隐藏旧代码的低劣质量，同时为新的层次提供一组一致的服务。这样，你的系统的其他部分就只需与这一层进行交互，而无须直接同旧代码打交道了。在这个例子中，层次化设计的益处有：（1）它把低劣代码的烂泥潭禁闭起来；（2）如果你最终能抛弃或者重构旧代码，那时就不必修改除交互层之外的任何新代码。交叉参考 一种特别有价值的标准化就是使用设计模式，在第5.3节“查阅常用的设计模式”中会有论述。标准技术 一个系统所依赖的外来的、古怪的东西越多，别人在第一次想要理解它的时候就越是头疼。要尽量用标准化的、常用的方法，让整个系统给人一种熟悉的感觉。Levels of Design设计的层次需要在一个软件系统中的若干不同细节层次上进行设计。有些设计技术适用于所有的层次，而有些只适用于某些层次上。图5-2展示了这些层次：图5-2 一个程序中的设计层次。系统（1）首先被组织为子系统（2）。子系统被进一步分解为类（3），然后类又被分解为子程序和数据（4）。每个子程序的内部也需要进行设计（5）。换言之整个公司的巨大成功基于这条如岩石般坚固的原则：他们的基础设计缺陷完全被其表层的设计缺陷所隐藏。Douglas AdamsLevel 1: Software System第1层：软件系统第一个层次就是整个系统。有的程序员直接从系统层次就开始设计类，但是往往先从子系统或者包（package）这些类的更高组织层次来思考会更有益处。Level 2: Division into Subsystems or Packages第2层：分解为子系统或包在这一层次上设计的主要成果是识别出所有的主要子系统。这些子系统可能会很大，比如说数据库、用户界面、业务规则、命令解释器、报表引擎等。这一层的主要设计活动就是确定如何把程序分为主要的子系统，并定义清楚允许各子系统如何使用其他子系统。对于任何至少需要几周时间才能完成的项目，在这一层次上进行划分通常都是必需的。在每个子系统的内部可能要用到不同的设计方法请对系统中的每一部分选用最恰当的方法。在图5-2中，这一层次的设计是用注明的。在这一层次中，有一点特别重要，即不同子系统之间相互通讯的规则。如果所有的子系统都能同其他子系统通讯，你就完全失去了把它们分开所带来的好处。应该通过限制子系统之间的通讯来让每个子系统更有存在意义。举例来说，在图5-3中，你把一个系统划分成六个子系统。在没有定义任何规则时，热力学第二定律就会发生作用，整个系统的熵将会增加。熵之所以增加的一种原因是，如果不对子系统间的通信释加任何限制，那么它们之间的通信就会肆意地发生，如图5-4所示：图5-3 一个有六个子系统的系统示例图5-4 当子系统之间的通信没有任何限制时就会像这个样子正如你所看到的，这里的每个子系统最终都会直接与所有其他子系统进行通信，从而为我们提出一些重要的问题： 一个开发人员需要理解系统中多少个不同的部分哪怕只理解一丁点儿才能在图形子系统中改动某些东西？ 当你想在另一个系统中试图使用业务规则时会发生什么？ 当你想在系统中加入一套新的用户界面时比如说为了进行测试而开发的命令行界面会发生什么？ 当你想把数据存储放到一台远程计算机上，又会发生什么？你可以把子系统之间的连线当成水管。当你想去掉某个子系统时，势必会有不少水管连在上面。你需要断开再重新连接的水管数量越多，弄出来的水就会越多。你肯定想把系统的架构设计成这样：如果想把某个子系统取走重用时，不用重新连接太多水管，重新连接起来也不会太难。有先见之明的话，所有这些问题就不会花太多额外功夫。只有当“确需了解”最好还有合理的理由时，才应该允许子系统之间的通讯。如果你还拿不准该如何设计的话，那么就应该先对子系统之间的通讯加以限制，等日后需要时再放松，这要比先不限制，等子系统之间已经有了上百个调用时再加以限制要容易得多。图5-5就展示了施加少量通讯规则后可以把图5-4中的系统变成什么样子：图5-5 施加若干通信规则后，子系统之间的交互得以显著地简化为了让子系统之间的连接简单易懂且易于维护，就要尽量简化子系统之间的交互关系。最简单的交互关系是让一个子系统去调用另一个子系统中的子程序；稍微复杂一点的交互关系是在一个子系统中包含另一个子系统中的类；而最复杂的交互关系是让一个子系统中的类继承自另一个子系统中的类。有一条很好的基本原则，即，像图5-5这样的系统层设计图应该是无环图（acyclic graph）。换句话说，程序中不应该有任何环形关系，比如说A类使用了B类、B类使用了C类、而C类又使用了A类这种情况。对于大型程序或一系列程序而言，在子系统这一层次上进行设计是至关重要的。如果你觉得自己要写的程序小到可以跳过在子系统层次上进行设计这一步骤，那么只要确保跳过这层设计的决定是经过深思熟虑的。常用的子系统 有些种类的子系统会在不同的系统中反复出现。下面几种就较为常见：交叉参考 于用表格表示业务逻辑，以简化编程，见第18章“表驱动法”。业务规则 业务规则是指那些在计算机系统中编入的法律、规则、政策以及过程。如果你在开发一套薪资系统，你可能要把美国国税局关于允许扣提的金额和估算的税率编到你的系统中。在薪资系统中还可能出现的规则包括与工会签订的有关加班率、休假安排以及节假日薪水的合同，等等。如果你要写一个能计算车险费率的程序，那么业务规则可能会包括政府有关责任范围的法令、保险赔率表以及保险业条款等。用户界面 应创建一个子系统，把用户界面组件同其他部分隔离开，以便使用户界面的演化不会破坏程序的其余部分。在大多数情况下，用户界面子系统会使用多个附属的子系统或类来处理用户界面、命令行接口、菜单操作、窗体管理、帮助系统，等等。数据库访问 你可以把对数据库进行访问的实现细节隐藏起来，让程序的绝大部分可以不必关心处理底层结构的繁琐细节，并能像在业务层次一样处理数据。隐藏实现细节的子系统可以为系统提供有价值的抽象层，从而减少程序的复杂度。它把和数据库相关的操作集中起来，减少了在对数据进行操作时发生错误的几率。同时，它还能让数据库的设计结构更易于变化，做这种修改时无须修改程序的主要部分。对系统的依赖性 把对操作系统的依赖因素归到一个子系统里，就如同把对硬件的依赖因素封装起来一样。比如说，你在开发一个运行于Microsoft Windows操作系统上的程序，可为什么一定要把自己局限于Windows的环境呢？把所有与Windows相关的系统调用都隔离起来，放到一个Windows接口子系统中，这样一来，如果日后你想把程序移植到Mac OS或Linux操作系统时，只要修改接口子系统就可以了。自己实现这一接口子系统可能会太复杂了，但一些商业代码库都已经提供了这一子系统的现成实现。Level 3: Division into Classes第3层：分解为类深入阅读 关于数据库设计，请参阅Agile Database Techniques (Ambler 2003)，在这一层次上的设计包括识别出系统中所有的类。例如，数据库接口子系统可能会被进一步划分成数据访问类、持久化框架类以及数据库元数据。图5-2中的第3层就展示了第2层中一个子系统是如何被分解为类的，当然这也暗示着第2层的其他三个子系统也被分解为类了。当定义子系统中的类时，也就同时定义了这些类与系统的其余部分打交道的细节。尤其是要确定好类的接口。总的来说，这一层的主要设计任务是把所有的子系统进行适当的分解，并确保分解出的细节都恰到好处，能够用单个的类实现。交叉参考 关于高质量的类的具体特性，见第6章“可以工作的类”。对于工作期需要超过几天的项目而言，通常就需要把子系统分解为类了。如果项目很大，这种分解就会与第2层的程序分解有明显的区别；相反，如果项目很小，你也可以直接从第1层的系统全局视图直接进入到第3层的类视图。类与对象的比较 面向对象设计的一个核心概念就是对象（object）与类（class）的区分。对象是指运行期间在程序中实际存在的具体实体（enity），而类是指在程序源码中存在的静态事物。对象是动态的，它拥有你在程序运行期间所能得到的具体的值和属性。例如，你可以定义一个名为Person的类，它具有姓名、年龄、性别等属性。在程序运行期间，你可以有nancy、hank、diane、tony等对象它们是类的具体实例。如果你熟悉数据库术语的话，类与对象的关系就如同“模式（schema）”与“实例（instance）”一样。你可以把类看做是蛋糕模具，而把对象看做是蛋糕。在本书中，对这两个术语的使用并非十分正规，一般情况也会或多或少互换地使用类和对象这两个术语。Level 4: Division into Routines第4层：分解成子程序这一层的设计包括把每个类细分为子程序。在第3层中定义出的类接口已经定义了其中一些子程序，而第4层的设计将细化出类的私用（private）子程序。当你查看类里面子程序的细节时，就会发现很多子程序都很简单，但也有些子程序是由更多层次化组织的子程序所组成的，这就需要更多的设计工作了。完整地定义出类内部的子程序，常常会有助于更好地理解类的接口，反过来，这又有助于对类的接口进行进一步修改，也就是说再次返回第3层的设计。这一层次的分解和设计通常是留给程序员个人来完成的，它对于用时超过几小时的项目而言就是必需做的了。虽然不用非常正式地完成这一步骤，但至少也要在脑中完成。1155.3 设计构造块：启发式方法交叉参考 关于创建高质量的子程序的具体做法，见第7章“高质量的子程序”和第8章“防御式编程”。Level 5: Internal Routine Design第5层：子程序内部的设计5.3在子程序层次上进行设计就是为每个子程序布置详细的功能。子程序内部的设计工作通常是由负责该子程序的开发人员来完成的。这里的设计工作包括编写伪代码、选择算法、组织子程序内部的代码块、以及用编程语言编写代码。这一层的设计工作总是需要做的，尽管有时做得很不在意或者很差劲，有时则是经过深思熟虑而出色完成的。在图5-2中的第5步就是这一层的设计工作。Design Building Blocks: Heuristics设计构造块：启发式方法软件开发人员希望我们能给出明确的答案：“只要做了A、B、C，就一定会得到X、Y、Z的结果。”我们在学会一些神秘技术并用它们实现了预期结果后会感觉骄傲，也会因为某些方法并未应验而感觉懊恼。对于具体的编程工作来说，期待确定性的行为是很正常的无论这种对细节的关注会给程序带来好处还是坏处。然而对于软件设计来说却并非如此。由于软件设计是非确定性的，因此，灵活熟练地运用一组有效的启发式方法（试探法），便成了合理的软件设计的核心工作。下面将几小节将阐述一些启发式方法，也即一些思考问题的方法，它们有时能够产生优秀设计成果。你可以把启发式方法看做是指引试错(trail and error)法中“试验”部分的指导书，你也一定曾经用过其中一些方法。因此，以下部分会依据软件的首要技术任务管理复杂度的原则来讲解每一种启发式法。Find Real-World Objects寻找现实世界中的对象Ask not first what the system does; ask WHAT it does it to!Bertrand Meyer在确定设计方案时，首选且最流行的一种做法便是“常规的”面向对象设计方法，此方法的要点是辨识现实世界中的对象（object，物体）以及人造的（synthetic）对象。使用对象进行设计的步骤是：交叉参考 关于设计和使用类的更多细节，见第6章“可以工作的类”。 辨识对象及其属性（方法(method)和数据(data)）。 确定可以对各个对象进行的操作。 确定各个对象能对其他对象进行的操作。 确定对象的哪些部分对其他对象可见哪些部分可以是公用(public)的，哪些部分应该是私用(private)的。 定义每个对象的公开接口(public interface)。这些步骤并无须以特定顺序来完成，它们也经常会被反复执行。迭代是非常重要的。下面来总结一下每一个步骤：辨识对象及其属性 计算机程序通常都是基于现实世界的实体。例如，你可以基于现实世界中的雇员（Employee）、顾客（Client）、工作时间记录卡（Timecard）以及账单（Bill）等实体来开发一套按时间计费的（time-billing）系统。图5-6显示了这样一套收费系统的面向对象视图。图5-6 收费系统由四种主要的对象构成，这些对象在本例中进行了一定的简化。辨识对象的属性并不比辨识对象本身更困难。每个对象都有一些与计算机程序相关的特征。例如，在这个收费系统里，每个雇员对象都具有名字（name）、职务（title）和费率（billingRate）等属性；而顾客对象则具有名字（name）、帐单寄送地址（billingAddress）以及账户余额（accountBalance）等属性；账单对象具有收费金额、顾客名字、支付日期（billDate）；如此等等。图形用户界面系统中的对象可能包括窗体、对话框、按钮、字体以及画图工具等。相比于“把软件中的对象一一映射为现实世界中的对象”，深入挖掘问题领域可能会得出更好的设计方案，不过从现实世界中的对象入手的确是不错的起点。定义可对对象执行的操作 在每个对象之上都可以执行多种操作。在图5-6所示的收费系统里，雇员对象可能需要修改职务或者费率，顾客对象可能需要修改名字或者帐单寄送地址，等等。确定可以每个对象可以对其他对象进行的操作 这一步骤的目的显而易见。对象之间最常见的两种关系是包含（containment）和继承（inheritance）。哪些对象可以包含其他对象？哪些对象又可以从其他对象继承？图5-6中，一个Timecard对象可以包含一个Employee对象和一个Client对象，一个Bill对象可以包含一个或多个Timecard对象。另外，一份账单可以标示是否已经给某位顾客开过帐单了，而顾客也可以签付一份账单。更复杂的系统中还会包含其他更多的交互关系。交叉参考 关于类何信息隐藏的详细情况，见第5.3节中的“隐藏秘密（信息隐藏）”。确定对象的哪些部分对其他对象可见 一项关键的设计决策就是明确对象的哪些部分应该是公开的（public），哪些部分又应该是不公开的（private）。对数据和方法都要做这一决策。定义每个对象的接口 在编程语言的层次上为每个对象定义具有正式语法的接口。对象对其他对象暴露的数据及方法都被称为该对象的“公开接口/public interface”，而对象通过继承关系向其派生对象暴露的部分则被称为“受保护的接口/protected interface”。要考虑这两种不同的接口。经过上述这些步骤得到了一个高层次的、面向对象的系统组织结构之后，你可以用这两种方法来迭代：在高层次的系统组织结构上进行迭代，以便更好地组织类的结构；或者在每一个已经定义好的类上进行迭代，把每个类的设计细化。Form Consistent Abstractions形成一致的抽象抽象是一种能让你在关注某一概念的同时可以放心地忽略其中一些细节的能力在不同的层次处理不同的细节。任何时候当你在对一个聚合物品（aggregate）工作时，你就是在用抽象了。当你把一个东西称为 “房子”而不是由玻璃、木材和钉子构成的组合体时，你就是在用抽象了。当你把一组房屋称为“城镇”时，你还是在使用抽象。基类也是一种抽象，它使你能集中精力关注一组派生类所具有的共同特性，并在基类的层次上忽略各个具体派生类的细节。一个好的接口也是一种抽象，它能让你关注于接口本身而不是类的内部工作方式。一个设计良好的子程序接口也在较低的层次上提供了同样的好处，而设计良好的包（package）和子系统的接口则在更高的层次上提供了同样的好处。以复杂度的观点看，抽象的主要好处就在于它使你能忽略无关的细节。大多数现实世界中的物体（object，对象）都已经是某种抽象了。正如上面所提到的，房屋是门、窗、墙、线路、管道、隔板等物体及其特定的组织方式所形成的抽象。同样，门是一块长方形材料加上合叶和把手以及一种特定的组织方式的抽象。而门把手又是铜、镍、铁、钢等的一种特定形式的抽象。人们一直都在使用抽象。如果每天你开门的时候都要单独考虑那些木纤维、油漆分子以及铁原子的话，你就别想再出入房间了。正如图5-7所示，抽象是我们用来得以处理现实世界中复杂度的一种重要手段。图5-7 抽象可以让你用一种简化的观点来考虑复杂的概念交叉参考 关于在类的设计中使用抽象的详情，见第6.2节中的“好的抽象”。软件开发人员有时就是在木材纤维、油漆分子以及铁原子这一层次来构建系统，系统因此变得异常复杂，难以通过人的智力去管理。当程序员没有给出足够高层的编程抽象时，系统有时就会被卡在门口了。优秀的程序员会在子程序接口的层次上、在类接口的层次上以及包接口的层次上换句话说，在门把手的层次上、门的层次上以及房屋的层次上进行抽象，这样才能更快、更稳妥地进行开发。Encapsulate Implementation Details封装实现细节封装填补了抽象留下的空白。抽象是说：“可以让你从高层的细节来看待一个对象。”而封装则说：“除此之外，你不能看到对象的任何其他细节层次。”继续刚才关于房屋材质的比喻：封装是说，你可以从房屋的外面看，但不能靠得太近去把门的细节都看清楚。可以让你知道哪里有门，让你知道门是开着的还是关着的，但不能让你知道门是木质的、纤维玻璃的、钢质的还是其他什么材质的，当然就更不能让你看到每一根木纤维。如图5-8所示，封装帮助你管理复杂度的方法是不让你看到那些复杂度。在第6.2节中的“良好的封装”中还会对进一步阐述这一话题，讨论如何把它应用于类的设计。图5-8 封装是说，不只是让你能用简化的视图来看复杂的概念，同时还不能让你看到复杂概念的任何细节。你能看得到的就是你能全部得到的！InheritWhen Inheritance Simplifies the Design当继承能简化设计时就继承在设计软件系统时，你经常会发现一些大同小异的对象。比如说，在一套账务系统中包含有全职员工和兼职员工，两者的大多数数据是相同的，只是某些数据不同。在面向对象编程时，你可以定义一个代表普通员工的通用（general）类型，然后把全职员工定义为普通员工除了有一些不同之处；同样，把兼职员工也定义为普通员工除了一些不同之处。当一项针对员工的操作与具体的员工类别无关时，这一操作就可以仅针对通用员工类型来进行。当该操作需要区别全职员工与兼职员工时，就需要按照不同的方法来处理了。定义这种对象之间的相同点和不同点就叫“继承”，因为特殊的全职员工类型和特殊的兼职员工类型都从基本员工类型继承了某些特征。继承的好处在于它能很好地辅佐抽象的概念。抽象是从不同的细节层次来看对象的。回想一下前面讲过的，门从某个层次上看是不同种类的分子，而从另外的层次上看则是木纤维，再从另外一层上看它又是能够阻挡盗贼的东西。木头具有一些属性，比如说，你可以用锯来锯断木头，或用乳胶来粘合它们。三合板或雪松木除了具有木头的基本属性之外，还有一些它们自己特有的属性。继承能简化编程的工作，因为你可以写一个基本的子程序来处理只依赖于门的基本属性的事项，另外写一些特定的子程序来处理依赖特定种类的门的特定操作。有些操作，如Open()或Close()，对于任何种类的门都能用，无论它是防盗门、室内门、户外门、玻璃门、法式门还是滑动玻璃门。编程语言如果能支持像Open()或Close()这样在运行期间才能确定所针对的对象的实际类型的操作，这种能力叫做“多态/polymorphism”。面向对象编程语言，如C+、Java以及较新版本的Microsoft Visual Basic都支持继承和多态。继承是面向对象编程中最强大的工具之一。如果使用得当，它能带来极大的益处，然而如果使用不当，它也有极大的弊端。详见第6.3节中的“继承（是一个关系）”。Hide Secrets (Information Hiding)隐藏秘密（信息隐藏）信息隐藏是结构化程序设计与面向对象设计的基础之一。结构化设计里面的“黑盒子”概念就是来源于信息隐藏。在面向对象设计中，它又引出了封装和模块化的概念，并与抽象的概念紧密相关。信息隐藏是软件开发中一个开拓性的概念，这一节将会就此进行深入论述。1972年，David Parnas发表的一篇题为论将系统分解为模块的准则的论文首次让公众注意到信息隐藏这一概念。信息隐藏被认为是具有“保密”的特征，软件开发者把一个地方的设计和实现决策隐藏起来，使程序的其他部分看不到它们。在人月神话的20周年纪念版中，Fred Brooks总结说，旧版中存在几处错误，其中之一便是对信息隐藏的批评。他说，“Parnas是对的，而我在信息隐藏方面的观点才是错误的。”（Brooks1995）。Barry Boehm撰文称，信息隐藏是减少重复工作的强大技术。他同时指出，信息隐藏在不断增长的、大量变化的环境中尤其有用（Boehm 1987）。信息隐藏是软件的首要技术任务中格外重要的一种启发式方法，因为它强调的就是隐藏复杂度，这一点无论是从它的名称还是其实施细节上都能看得很清楚。Secrets and the Right to Privacy秘密和隐私权当信息被隐藏后，每个类（或者包和子程序）都代表了某种对其他类保密的设计或构建决策。隐藏起来的秘密可能是某个易变的区域，或者某种文件格式，或某种数据类型的实现方式，或某个需要隔离的区域，在这个区域中发生的错误不会给程序其余部分带来太大损失。在这里，类的职责就是把这部分信息隐藏起来，并保护自己的隐私权。对系统的非重大改动可能会影响到某个类中的几个子程序，但它们不应该波及到类接口的外面。类的接口的奋斗目标是完备且最小。Scott Meyers在设计一个类的时候，一项关键性的决策就是确定类的哪些特性应该对外可见，而哪些特性应该隐藏起来。一个类可能有25个子程序，但只暴露了其中的5个，其余20个则仅限于在类的内部使用。一个类在内部可能用到了多种数据类型，却不对外暴露有关它们的任何信息。在类的设计中，这一方面也称为“可见性（visibility）”，因为它要确定的就是类的哪些特性对外界是“可见的”或能“暴露”给外界。类的接口应该尽可能少地暴露其内部工作机制。如图5-9所示，类很像是冰山：八分之七都是位于水面以下，而你只能看到水面上的八分之一。图5-9 好的类接口就像是冰山的尖儿一样，让类的大部分内容都不会暴