如何设计代码, 设计方法和过程!

在设计时始终要在最接近的环境中进行考虑——房间中的椅子、房屋中的房间，环境中的房屋，城市规划中的环境等。

——埃利尔·沙里宁（Eliel Saarinen）

如何才能学会良好的设计？优秀的设计人员是天生的还是后天形成的？设计是要靠经验的逐步积累，还是很快就能掌握？有些程序员在良好的设计方面很有天赋，他们的大脑天生就适合做设计。他们生来就具有杰出的审美能力，并且能够充分地理解问题，以做出均衡的判断。不过，你的确也可以通过训练学会如何进行更有效的设计。

在刚出生时，我并不擅长陶艺。（我从未遇到刚出生就擅长陶艺的人。）我现在的陶艺仍然很糟糕。不过，我曾经接受过一些培训。我了解了制陶中的一些问题，并且可以做出（几乎是有形的）陶器了。如果我再多练习练习，那么我的匠艺很可能会变得更好。但是，我永远成不了艺术大师。

同样，没有谁生来就会设计代码：我们需要学习。我们要掌握许多设计方法和良好的编程习惯。这些知识旨在使设计成为一种可重复的过程，但是它们并不能取代具体的设计技术。创造性的思维过程和富有创意的设计理念是很难掌握的，可总是存在精通此道的更优秀的设计人员。

良好的软件设计是富有美感的，为了创建这种数字艺术，需要大量的技术、经验和实践。本章不打算平淡无奇地描述如何设计软件。真遗憾，如果我能轻易地做出优秀的设计，那么我早就是百万富翁了。要想成为一名优秀的设计人员，你必须掌握构成良好设计的各种要素，并学会回避糟糕设计的特征。然后就去实践吧。要持之以恒。

除了个人能力之外，还有许多可以帮助程序员的设计方法和工具。我们将在本章的最后研究它们可以（或不可以）给予我们哪些帮助。

软件的设计方法有很多。其中一些方法强调图示，另外一些则强调过程。系统化的方法要好于只凭直觉式的设计，你使用哪种方法通常是由公司的惯例和文化决定的。我总是担心会过多地局限于某种特定的过程，因为过分地满足它的细节会抑制创造力。

现代设计方法主要分为两类，它们所基于的基本设计理念如下。

这种设计主要与功能分解有关，即将系统的功能分解为一系列更小一些的操作。例程是主要的结构化手段；结构化设计就是由一个例程的层次结构组成的。结构化设计以“分治”（divide-Ａnd-conquer）法为主要特征，即把问题不断地分解成若干个更小的问题，直到每个小问题无法再被分解为止。

分解问题的方式有两种：自顶向下和自底向上。

— 顾名思义，自顶向下的方法会从整个问题着手，并将它分解为若干个更小的问题。接下来，这些小问题会被分解为更小的单元，直到没有必要再分解下去为止。

— 相反，自底向上的设计从最小的功能单元（也就是你了解的系统必须做的最小的事情）着手。然后，将这些功能组合起来，直到形成一个完整的解决方案。

在实践中，会同时采用这两种设计方法，设计的过程将在它们相遇的地方（通常在中间某个位置）结束。

结构化设计的焦点在于系统必须执行的操作，而面向对象设计的焦点则在于系统中的数据。这种方法将软件设计为一些相互作用的独立单元，这种单元被称为“对象”。

面向对象的设计将确定问题域中的主要对象，并规定这些对象的特征。这些对象的行为，包括这些对象所提供的操作，以及每个对象与其他哪些对象相关等，都将被确立下来。所有对象都将被组织在设计中，从而合并了对象所需的任何实现域。当所有的对象行为和相互作用都被确定之后，设计就完成了。

面向对象的程序设计曾被誉为软件设计界的救星，引领世界和平的新典范。它得到的赞誉是如此之多，以至于人们如果没有执行面向对象的设计，就常常会感到难堪。不过，这种方法确实不负众望，它使得软件设计可以处理极为复杂的大型问题。

关于设计方法和过程的详细描述，请参见第420页的“编程风格”。

设计模式

近些年来，“模式”逐渐成为了面向对象程序设计界的一个时髦的字眼。随着被称作“四人组”（Gang of Four，也常被称作GoF）的作者所著的《设计模式：可复用面向对象软件的基础》一书（Gammaetal.94）的出版，设计模式被广为传播，从而成为了Christopher AlexＡnder的体系结构工作的软件版本。（AlexＡnder99）

模式建立了一个已验证的设计方案的符号集合，其中每种模式都描述了一个对象相互协作的可识别的结构。这些设计不是什么聪明的发明，而是在现实代码中反复出现并证明有效的模式。“模式语言”整理对比了一系列的设计模式，揭示了它们之间的相互关系。语言中的每一种模式都符合一种通用的形式，对上下文、问题和解决方案进行了描述。这些信息使你可以在设计中恰当地运用模式。

模式体现在软件系统中的好几个层面上。体系结构的模式对系统的组织形式具有极为深远的影响。设计的模式确定了软件组件中间一级的协作方式。语言层面的模式则是具体的代码技术，通常会被称为“语言习惯”。

设计模式的名称已经进入到日常的对话中，这也证明了它们已被广泛地使用。你会经常听到程序员们愉快地谈论着adaptor、observer、factory和singleton等概念。

设计模式远远不是几句话就能够说清楚的。它们是极为有用的概念，花一些时间去了解它们是非常值得的，要阅读一些GoF的书籍以及其他相关的资料。

我们的设计最终会体现在代码中，不过如果在一个更为抽象的层面上工作，往往会对我们有所帮助。工具可以帮助我们对某种设计进行讨论，帮助我们创造出更高效的设计，还帮助我们将这些设计传达给其他的程序员——记录我们打算做什么，以及我们已经做了些什么。

在某种意义上讲，方法也是一种工具，不过还有许多其他用于完善这些设计方法的辅助工具。

美观的图片与词语一样有价值。现有的许多图形表示法，有助于图形化地表达我们的设计。大多数图形表示法都只会短暂地流行，然后就悄悄地退出了人们的视野，而被更加吸引人的图形表示法取代。统一建模语言（UML）是目前最流行且定义良好的表示法。它提供了一种标准的方式，来对软件开发过程中产生的几乎每一个结果进行建模和文档化。事实上，这种表示法已经非常全面，以至于你都可以使用它来表达软件之外的很多东西，它已经被用在软件、业务流程甚至组织结构的建模中。

图形表示法提供了一种媒介，可以帮助你表达、思考和讨论你的软件设计。它们有两个作用：

— 它们使你可以在一张稿纸上快速地做出设计的草稿，并在一块白板上与同事们分享你的想法；

— 它们使你可以在形式上使设计文档化。

为了使你在后一种情况下保持头脑清醒，你必须使用一种专用的画图工具来自动创建图表。否则，图表将很难更新，并且会在开发代码的过程中与现实脱节。把时间花在做有益的事情上，而不只是画几个方框和线条。

我不喜欢过于正式地使用某种表示法，而只愿意把它用作一种与别人分享设计主要元素的沟通手段。了解如何使用它们来进行沟通，对我而言就已经足够了。我并不想过多地关注各种图片类型中的每个菱形和虚线所代表的含义。

设计模式是一种强大的设计工具，它提供了一个已验证的设计技术的符号集合，并说明了如何在实际中应用这些技术。第255页的“设计模式”对此进行了深入的讨论。

流程图是一种特别的图形表示法，用于可视化地表达算法。它们可以给出整体的概览，但是不如代码精确，并且在改变代码时也要同步地进行更改。因此，在使用流程图时最好保守一些。

伪代码可以帮助你草拟函数的实现。它是软件设计中最奇特的发明中的一种。它介于自然语言和编程语言之间，只能算是一种混合的英语。它的优点是不受任何一种语言的语法和语义的约束。你可以只关注于需要做些什么，而不必考虑语法机制，而且为了清晰你也可以插入任意数量的描述性内容。

然而与它的缺点相比，它的优点并不是那么了不起。伪代码转需要被转换换成某种实现语言。你本来一开始就可以使用这种实现语言来编写代码，这样可以节省很多精力。如果伪代码被用来对设计进行文档化，那么你就不得不使它与代码保持同步。

程序设计语言（Program Design Language，PDL）是一种更加荒唐的发明——一种标准化了的伪代码。我想它也许有时会对某个人有一些意义。我很想看看他们的伪代码编译器。

这是一种很有用的非正式的代码设计方法。在设计的最初阶段，你在代码中放置了所有的API和低级接口，但是并没有真正实现它们——你只是编写了一些返回某种可能的值的代码片断，并在其中放置了一些描述还应该做哪些工作的注释。当你的设计足够成熟时，系统中就会有许多已经编写好的代码了。

这样做可能利弊参半，因为可能会导致设计的灵活性降低。设计的改动越多，需要更改的代码片段也就越多。

计算机辅助软件工程（CASE）工具可以帮助全部或部分的设计过程，使枯燥无味的工作变得自动化，并且可以控制工作流。这些工具大部分都能从你漂亮的设计图片直接生成代码（质量有所不同）。其中一些甚至可以在你修改代码时更新图片；这被称为“双向工程”（或双向转换）。许多CASE工具都支持协同工作，允许程序员团队共同创作一个大型设计。

快速应用程序开发（RAD）工具是一种值得一提的CASE工具，它用于快速构建应用程序的环境。这种工具倾向于在它们特定的领域（通常是简单UI应用程序）中比较有效，但不是优秀的通用软件设计模型。