对于模式的“十大误解”02

误解之二：“模式就是行话、规则、编程技巧、数据结构⋯⋯”

我通常把这些误解统称为“蔑视”。如果你试图把某些不熟悉的东西简化为熟悉的东西，产生这种想
法是很自然的，尤其是当你没有特别的兴趣去钻研这些不熟悉的东西时。另外，某些人经常拿新瓶装陈酒，然后大吹“创新”、“革命”一类的口号。保持警惕也是好的。

但是，这种蔑视通常不是来自亲身体验，而是来自肤浅的认识和一点点冷嘲热讽。而且，没有什么东西是真正“全新”的。人们的脑海中一直都存在着各种各样的模式，只不过我们现在刚开始为模式命名，并将模式记录下来。

来逐个说明这些看法：的确存在着模式的行话，例如“模式”这个词，例如“约束”，例如Alexander
的“无名质量”，等等。但是模式是不能简化为行话的。与其他计算机科学领域相比，模式引入的新术语实在是少得可怜。对于听众来说，好的模式本来就很容易接受。在说明一个模式的时候也许有必要引用问题领域的行话，但是几乎没有必要使用什么特定于模式领域的术语。

没有哪个模式是能让你不假思索就使用的规则（组件则正好相反），同时模式也不仅仅是“编程技巧”，尽管模式中的“方言（idiom）”部分是特定于语言的。在我听来，“技巧”这个词带有轻蔑的意思，并且过分强调解决方案，而忽视了问题、场景和名称的重要性。

毫无疑问，你也曾经听说过一次创新被接受的三个阶段：首先，它被当作垃圾扔在一边；然后，人们会认为它不具可实施性；最后，大家都明白它的意义时，它也没有意义了——“我们一直都这样做”。现在，模式还没有完全走出第一个阶段。

误解之三：“理解一个，就理解了全部”

一刀切的规则往往是不公平的，而人们对模式却更加一刀切。模式的领域、内容、范围、形
式、质量⋯⋯这个领域大得吓人，只需要随手翻翻PLoP 的书[CS95, MRB98, VCK96]就能看出。不
同的人写出不同的模式，而模式的变化甚至比作者还要多。象Alistair Cockburn、Jim Coplien、Neil Harrison 和Ralph Johnson 这样的作者已经超越了最初大量记录不同领域、不同形式模式的阶段。

只看几个例子就对模式做一个笼统的结论，这样的结论必定是错误的。

误解之四：“模式需要有工具或方法学的支持才会有效”

在过去的五年中，我记录、使用并且帮助其他人使用模式，还至少帮助完成了一个基于模式
的工具[BFV+96]，所以我可以很有把握的说：模式的绝大多数好处都来自于原封不动的使用——
也就是说，不需要任何形式的支持。

在谈到这个主题的时候，我通常会指出模式带来的四大好处：

1. 它们记录了专家的经验，并且让非专家也能理解。
2. 它们的名称构成了一份词汇表，帮助开发者更好的交流。
3. 它们帮助人们更快的理解一个系统——只要这个系统是用模式的方式描述的。
4. 它们使系统的重组变得更容易，不管原来的系统是否以模式的方式设计的。

过去，我一直认为第一项是模式最大的好处。现在我认识到，第二条起码也同样重要。请想一想，在一个开发项目的过程中，有多少字节的信息在开发者之间流动（包括口头的和电子的）？我猜就算没有1G也有好几兆。（在推出了《设计模式》之后，我已经收到了好几十兆给GoF 的电子邮件。而且我们所描述的还都是小型到中型的软件开发项目。）由于有如此之大的信息交流量，所以效率上任何微小的提升都能大量节约时间。在这个意义上，模式拓宽了人们交流的带宽。我对第三、四条的评价也在逐渐提高，特别是在项目越来越大、软件生存周期越来越长的今天。

至少在短期内，模式主要存在于大脑中，而不存在于工具中。如果有了方法学或自动化工具的支持，应该还有其他的收益，但是我相信这些都只是蛋糕上的奶油，而不是蛋糕本身，甚至都不能算蛋糕的一层。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
到目前为止，我说到的误解都是关于“模式是什么”的。现在来看看关于“模式可以做什么”的误解。
这里有两种不同的风格：夸大其词的和心存疑虑的。