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

John Vlissides 著，透明译

最近，围绕着模式的讨论日嚣尘上，人们对模式的混淆、惊惶和以讹传讹已经不是一点半点。这也从一个侧面反映出对于主流软件开发者来说，模式是一个多么新鲜的领域——尽管严格说来，它并不是一个新的领域。同时，模式也是一个飞速发展的领域，留下了大片的空白。而且，没错，我们这些模式的支持者也应该受批评，因为我们没有把自己的知识完完全全地教给别人。尽管我们这样想过，但是却没有这样做[BMR+96, Coplien96, CS95, GoF95, MRB98, VCK96]。

因此，我觉得自己有责任来纠正一些模式方面越来越夸张的误解——我常常听到的那些误解都足以形成自己的模式了。甚至连我也曾经想以模式来组成自己的软件结构⋯⋯后来我才明白：“把所有的东西都变成模式”，这种想法本身就是错误的！总之，请记住，这篇文章不是在给模式社群的人们看的。我想，绝大多数的模式专家都会同意：下面这些都是很常见的误解。但是他们也许不会同意我消除这些误解的方式。

这几年以来，我听到过许多人谈论模式。把听到的这些东西整理一下，对模式的误解大概有三类：对于“模式是什么”的误解，对于“模式可以做什么”的误解，以及对于支持模式的人群的误解。我的“十大误解”都落入这三类之中，所以我就把这些误解都组织起来。首先，我们来看看关于“模式是什么”的误解。

误解之一：“模式是某种场景下某个问题的解决方案”

这个定义来自于 Christopher Alexander[AIS+77]，所以如果把它称为“误解”，也许有人会把我视为异端。但是下面这个简单的反例能让你看清它的缺点：

问题：我获奖的奖券就快过期了，我怎样拿到奖金？

场景：离截止时间只有一小时，可是我家的小狗把奖券给吞了。

解决方案：把狗开膛破肚，掏出奖券，然后飞奔到最近的兑奖地点。

这是“某种场景下某个问题的解决方案”，但它不是模式。还缺了什么？至少缺三样东西：

1. 可重复性。解决方案应该对应于外部的场景。

2. 可传授性。一个解决方案应该可以移植到问题的不同情况上。（绝大多数模式的可传授性都建立在“约束”和“效果”的基础上。）

3. 用来表示这个模式的名称。

确实，很难找到一个令人满意的定义。“模式讨论”邮件列表（patterns-discussion@cs.uiuc.edu）上正在进行的讨论也证明了这一点。难以定义的一大原因是：模式既是一个事物，也是对类似事物的描述。要区分这两者，有一种办法：“模式”这个术语只用来指代模式的描述，同时用“模式实例”来指代模式的具体应用。

但是，术语的定义很可能是白费力气，因为一个定义可能对一个人（比如程序员）有意义，但是对另一个人（比如只能看到书面材料的项目主管）却毫无意义。当然，我不打算在这里提出什么最终定义。但是，任何对模式要素的规定，除了必须包括问题、解决方案和场景之外，都必须提及可重复性、可传授性和名称。