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

抽象的风格

不同的语言以不同的方式处理抽象。阅读本文的人都熟悉一些普遍的抽象风格 — 例如结构化、模块 化和面向对象 — 它们出现在很多不同的语言中。当长时间使用一种特定的语言时，它就成了金锤：每个 问题看上去就像一个钉子，可以用该语言的抽象来驱动。对于纯面向对象语言（例如 Java 语言）来说， 这一点尤为明显，因为主要的抽象就是分层和易变状态。

Java 世界现在对一些函数式语言，例如 Scala 和 Clojure 表现出很大的兴趣。当使用函数式语言编 写代码时，您会以不同的方式思考问题的解决方案。例如，在大多数函数式语言中，默认方式是创建不可 变变量，而不是可变变量，这与 Java 截然相反。在 Java 代码中，默认情况下数据结构是可变的，必须 添加更多的代码，才能使它们具有不变的行为。这意味着以函数式语言编写多线程应用程序要容易得多， 因为不可变数据结构与线程交互起来非常自然，因而代码可以很简洁。

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

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

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

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

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

最初的 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 工件转换到代码，最终导致失败，因为这种制 图语言的表达性不足以

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!