23种设计模式的“十大误解”

现在“模式”这个词真是非常流行。就象任何流行的东西一样，对它的误解也真是不少。甚至在一些发表出来的文章中，也存在着各种各样的误解， 我想这会对读者造成非常糟糕的引导作用。早已想写一篇文章来澄清一些对模式的误解，却又因为水平所限难以成文。恰在此时， 我看到John Vlissides先生的《十大误解》，于是我便乐得当文抄公了。

　　关于设计模式，下面有十种错误的观点——很多都是很流行的观点。且看Vlissides先生如何拨开这些迷雾。

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

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

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

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

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

　　问题：我获奖的奖券就快过期了，我怎样拿到奖金？
　　场景：离截止时间只有一小时，可是我家的小狗把奖券给吞了。
　　解决方案：把狗开膛破肚，掏出奖券，然后飞奔到最近的兑奖地点。

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

　　1. 可重复性。解决方案应该对应于外部的场景。
　　2. 可传授性。一个解决方案应该可以移植到问题的不同情况上。（绝大多数模式的可传授性都建立在“约束”和“效果”的基础上。）
　　3. 用来表示这个模式的名称。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　至少在短期内，模式主要存在于大脑中，而不存在于工具中。如果有了方法学或自动化工具的支持，应该还有其他的收益，但是我相信这些都只是蛋糕上的奶油，而不是蛋糕本身，甚至都不能算蛋糕的一层。

* * *

　　到目前为止，我说到的误解都是关于“模式是什么”的。现在来看看关于“模式可以做什么”的误解。这里有两种不同的风格：夸大其词的和心存疑虑的。

误解之五：“模式可以保证软件的复用性、更高的生产力、世界的和平……”

　　道理很简单，模式什么都不保证。它们甚至有可能无法给你带来利益。在创造新事物的过程中，模式无法取代人的位置。它们只是带来一种希望，有可能让一个缺乏经验的、甚至是未入门的，但是有能力、有创造性的人尽快获得设计的能力。

　　人们经常说：好的模式会让读者有“啊！”的回应。实际上，只有当模式恰好拨动了读者的某一根心弦时，他们才会有这样的反应。如果没有，模式就只象森林里普通的一棵树。因此，什么是好的模式？不管它写得有多好，如果不能引起读者的共鸣，它又怎能算是好的模式？

　　模式只是开发者的工具箱中的另一件工具，对模式寄以过高的期望只会适得其反。准备充分，然后做最坏的打算——这就是防止受骗、消除对抗最好的方法。

　　误解之六：“模式可以‘生成’整个软件体系”

　　这个误解与上一个有点相似，不过侵略性稍微少些。

　　每过一段时间，模式论坛上就会讨论一次模式的生成能力。按照我的理解，“生成能力”是指模式创建最终行为的能力。很多人认为，模式可以帮助读者解决模式本身没有明确提出的问题。我读过的一些书里也有同样的观点。

　　对于我来说，“生成能力”的关键是模式的可传授性——约束及其解决，或者对于效果的讨论。在你定义、精炼一个体系结构时，这些观察是特别有用的。但是模式本身并不制造任何东西——任何东西都是由人来制造的。而且，模式不可能覆盖体系结构的每个方面。给我任何一个有实际价值的设计，我都能找出其中模式没有涉及的设计问题。也许这些问题不常见、不具可重复性，或者只是还没有以模式的形式记录下来。不管怎样，你都必须负责填补模式之间的空白——用你自己的创造性。

　　误解之七：“模式是针对（面向对象）设计或实现的”

　　另一个极端则是过分的限制，就象这个误解。坦白说，任何人都完全可能相信它，我不会有丝毫惊讶。无数的人问过我这个问题，所以它也进入了“十大误解”之列。如果你觉得这种观点实在天真幼稚，跳过这一部分吧。

　　如果模式不能记述专家的经验，那它们就什么都不是。对于模式的作者来说，任何形式的专家经验都是可记载的。当然，在面向对象软件设计中有值得记载的经验，但是在非面向对象设计和分析、维护、测试、文档、组织结构……这些方面也同样有值得记载的经验。现在，不同领域中的模式开始浮出水面。至少已经有两本关于分析模式的书[Fowler97, Hay96]，并且每次PLoP大会都会收到新的模式类型。（特别有趣的是1996年的PLoP大会甚至关注了音乐作曲的模式！）

　　和大多数的误解一样，这个误解也是有原因的。看看人们用来描述模式的格式，有两种基本的风格：描述高层结构的GoF风格（用于《设计模式》中）；接近文学的Christopher Alexander 风格——叙述性的，尽量少的结构图。由于已经用模式描述了面向对象设计之外的东西，所以我现在认识到GoF风格造成的偏差。对于我研究过的某些领域的专家经验，这种风格根本无法描述。为什么结构图看上去总是让人联想到C++？对于音乐作曲的模式，“实现”应该是什么？“协作”部分真的有意义吗？

　　很明显，一种格式不能适应所有的需求。比较具有普遍意义的是模式的概念：模式是记载并传达专家经验的工具——不论是哪个领域的专家经验。

误解之八：“没有证据表明模式帮助过任何人”

　　这种观点曾经有一定的说服力，但是现在已经没有了。在Software-Practice and Experience[Kotula96]这样的杂志上、在OOPSLA[HJE95, Schmid95]和ICSE[BCC+96]这样的会议上，人们不断的报告自己从模式得到的利益。Doug Schmidt已经清楚的说明了在传授计算机科学时使用模式的收益[PD96]。尽管绝大多数的证据都只是定性的，但是据我所知，至少有一个组织得到了一些定量的结论[Prechelt97,PUS97]。

　　随着时间推进，我们需要更好的掌握使用模式的好处和缺点。尽管最初的反馈已经让我们看到了希望，但是我们还需要更多的实践经验来做全面的估计。但是，如果仅仅因为模式的好处还没有完全证实就拒绝使用模式，那你就真的是个大傻瓜了。

* * *

　　关于“模式能干什么”的谬论还真不少。下面，最后两种误解不是关于模式本身，而是关于支持使用模式的人们的。

　　误解之九：“模式社群是精英的小圈子”

　　我很想知道这种观念到底是从哪里来的。如果说模式社群的人们有什么引人注目的地方，那就是他们之间巨大的差异。从PLoP大会的与会者名单就能看出——人们来自世界各地，有大公司的也有小公司的，有分析员、设计者和实现者，有学生也有教授，有大名鼎鼎的作者也有初出茅庐的菜鸟。更让我惊讶的是，竟然有不少与会者都不是计算机科学工作者！这个社群仍然在不停变化，每年的与会者名单都与前一年不同。

　　如果将模式社群的背景公开出来，别人也许会觉得奇怪：很少有学院派人士。实际上，绝大多数PLoP的与会者都是实践者。软件模式早期的推崇者——包括Kent Beck、Peter Coad 和Ward Cunningham——都没有学院背景。GoF中只有一个人（Ralph）是学院派，而且他也是我所认识的最实际的学院派。很明显，模式社群从根本上反对任何可能的宗派主义和精英论。

　　误解之十：“模式社群是自私的，甚至是阴谋家”

　　我不止一次的听人指责说：模式最大的用处就是为写模式书籍的人带来了源源不断的收入。他们甚至还暗示模式的发展有着某种邪恶的目的。

　　胡说八道！

　　作为GoF的一员，我可以肯定的告诉你：对于《设计模式》引起的反响，我们和其他任何人一样吃惊。对于它在OOPSLA 94上的初次亮相引起的暴风骤雨，我们也同样没有准备——甚至出版商都没有预料到会有这么大的销量。在整个写作过程中，我们最关心的就是尽量写出一本高质量的书，至于销售上的问题，我们根本没有时间去想。现在“模式”已经成了一个时髦的词汇，不可避免的会有一些人将这个词用来谋取私利。但是，如果你认真读过顶尖的模式作者的作品，你就会感觉到他们共同的目标：将难以获取的经验、最佳的实践、甚至是竞争中的优势——多年实践经验的累积——分享给读者，而且讲解得一清二楚。正是这种帮助读者的热情激励着每一个真诚而踏实的模式作者。如果没有这种热情，作者就会弄巧成拙——这种不负责任的作者往往正是对模式所有误解的根源！

                                                                                                                                    来源:赛迪网