演化架构和紧急设计: 利用可重用代码，第 1 部分：代码与设计之间的关系

抽象不是语言设计者的专利。2006 年，OOPSLA 上有一篇题为 “Collaborative Diffusion: Programming Antiobjects”的论文，其中介绍了 antiobject 的概念，这是一种特殊的对象，其行为方式与我们想象的刚好相反。这种方法用于解决论文中提出的一个问题： 如果我们受太多现实世界的启发而创建对象，那么对象的隐喻可以延伸到很远。

该论文的观点是，很容易陷入特定的抽象风格，使问题愈加复杂。通过将解决方案编写为 antiobject，可以换一个角度来解决更简单的问题。

这篇论文引用的例子非常完美地诠释了这个概念 — 这个例子就是 20 世纪 80 年代早期最初的 Pac-Man 视频控制台游戏（如 图 2 所示）：

图 2. 最初的 Pac-Man 视频游戏

最初的 Pac-Man 游戏的处理器能力和内存甚至不如现在的一些腕表。在这么有限的资源下，游戏设计者面临一个严峻的问题：如何计算迷宫中两个移动物体之间的距离？他们没有足够的处理器能力进行这样的计算，所以他们采取一种 antiobject 方法，将所有游戏智能构建到迷宫本身当中。

Pac-Man 中的迷宫是一个状态机，其中的每个格子根据一定的规则随整个迷宫的变化而变化。设计者发明了 Pac-Man 气味（smell） 的概念。Pac-Man 角色占用的格子有最大的 Pac-Man 气味，而最近腾出来的格子的气味值为最大气味减去 1，并且气味迅速衰退。鬼魂（追赶 Pac-Man，移动速度比 Pac-Man 稍快）平时随机闲逛，直到闻到 Pac-Man 的气味，这时它们会追进气味更浓的格子。再为鬼魂的移动增加一定的随机性，这就是 Pac-Man。这种设计的一个副作用是，鬼魂不能堵截 Pac-Man：即使 Pac-Man 迎面而来，鬼魂也看不到，它们只知道 Pac-Man 在哪里呆过。

换个角度简化问题使底层代码更加简单。通过转而抽象背景，Pac-Man 设计者在资源非常有限的环境中实现了他们的目标。当遇到特别难以解决的问题时（尤其是在重构过于复杂的代码时），问问自己，是否可以采用某种更有效的 antiobject 方法。

结束语

在本期中，我探讨了为什么表达性是重要的，以及代码中表达性的具体表现。我同意 Jack Reeves 对于不同工程的比较；我认为，完整的源代码就是软件中的设计工件。一旦理解了这一点，就可以为过去很多的失败找到解释（例如模型驱动的架构试图直接从 UML 工件转换到代码，最终导致失败，因为这种制图语言的表达性不足以捕捉所需的细微差别）。这种理解会带来一些负面影响，例如意识到设计（即编写代码）是花费最大的活动。这并不意味着在开始编写代码之前，不应该使用初期工具（例如 UML 之类的东西）来帮助理解设计，但是一旦进入编写代码阶段，代码就成为实际的设计。

设计的可读性很重要。设计的表达性越强，就越容易修改，并最终通过紧急设计从中收获惯用模式。在下一期，我将继续沿着这条思路，并提供利用从代码中收获的设计元素的具体方式。