第二讲：去藕.pdfVIP

第 2 讲 解藕（一） 软件设计的一个重要任务是怎样把一个程序分解成几部分。在这节课中，我们将为讨论 的各个部分介绍一些基本概念以及他们是如何彼此关联的。我们的焦点将是确认各部分之间 的耦合，以及显示如何降低耦合。在下次讲座中，我们将看到Java 是如何明确支持解藕技 术的。 今天我们将要介绍的一种关键思想是规范。不要认为规范是令人厌烦的文档。恰恰相反， 他们对于解藕非常重要，因此也对高质量的设计很重要。我们将看到，在更先进的设计里， 规范已成为重要的设计元素。 课程正文把使用和依赖看作同义词。在这次讲座中，我们将会区分这两个概念，并且解 释概念依赖如何比旧的概念使用更有用。你将需要理解怎样构造和分析依赖图；使用图仅仅 是构造依赖图的一个台阶。 2.1 分解 一个程序由多个部分组成的。这几部分是什么，他们是如何关联的？这就是分解的问题。 2.1.1 为什么分解？ Dijkstra指出如果一个程序有N部分，并且每部分的正确概率是 c ——即开发者弄错的 概率为 1-c ——那么整体程序正常工作的概率就是 。如果N很大，那么，除非 c 非常 接近1，否则 将趋近于零。Dijkstra 做这场辩论是为了表明把事情做好将花费多少—— 而且程序越大，事情就越多。如果你不能使每个部分近乎完美，那么让这个程序正常工作就 没有希望。（你可以在学术出版社于1972年由Dahl ，Dijkstra和Hoare编写的经典教材《结 构化编程》中找到这场辩论。）这是场诱人且优雅的辩论，但是也许有点令人误解。实际上， 无论如何整个程序完全正确的可能性为零。怎样才能保证那些有限的但很关键的属性被保 持，并且这些属性并没有包含每个部分。我们稍后将讨论。） 但是这难道表明我们不能把一个程序分成几部分吗？N越小，程序正常工作的可能性就 越高。当然，我在开玩笑——与大的相比较(因此参数c与N 并不相互独立) ，使小的部分正确 是很容易的。但是还是值得问一下把一个程序分成更小的部分有什么好处。这儿有一些： · 分工。一个程序不会无中生有：它必须被逐渐建造。如果你把它分成各部分，你就能通 过让不同的人在不同的部分工作来更快的建造它。 · 重用。有时不同的程序有相同的因素是可能的，因此它们可能被制造一次而使用很多次。 １ · 模块化分析。即使如果一个程序仅由一个人来做，分成各小部分中建造它也是有好处的。 每当一个部分完成时，就能够分析它的正确性（通过读代码，测试，或通过更多的稍候 将要讲的复杂的算法）。如果它有效，那它就能够被另一部分使用而不会被再次访问到。 除了给一个令人满意的成就感，这还有更细微的优势。 分析由两倍大的部分组成的整 体远远比单独分析每个部分困难。所以按各小部分分析程序能够显著地降低分析的总开 支。 · 局部变化。任何有用的程序将在它的一生中需要改写和扩展。如果一种变化能被局限在 一些小部分内，那么当确定需要变化时，作为整体需求，我们只需要考虑更小的一部分。 Herb Simon做了场激发兴趣的辩论，为什么结构倾向于在各分层的部分间建造——无 论是人造的还是自然的。他想象两位钟表工人，其中一位每次一个表一个表的造，而 另一个人造些合成部件然后把它们装配在一起。无论电话什么时候响，钟表工人都必 须停止并放下他目前的工作，组装就被破坏了。一次性建造表的钟表工会损坏掉所有 的表组件，而且必须从头再来。但是这个分步建造表的钟表工不会全部失去他做的工 作。所以他每次只失去较少的工作量，并且更有效地生产表。对于这场辩论将应用于 软件你是怎么认为的呢？（你可以在Simon的论文《复杂性的建筑》中找到这场辩论） 2.1.2 部分是什么？ 什么是一个程序被分成的部分？我们从现在开始将使用“部分”而不是“模型”以使我 们能够远离程序设计语言的专业观念。（在下一次的讲座中，我们将会看到JAVA是如何支 持分解的。）现在，我们所需要注意的是在一个程序中的规格说明部分：实际上，软件开发 真的是关于产生，分析和执行描述的。我们不久将会看到一个程序的各个部分并不都是可执 行代码——规格说明也是它非常有用的一个部分。 2.1.3 从上至下的设计 假设我们需要某一部分A并且我们想把它分解成各个部分。我们该如何进行正确的分解 呢？