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

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

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

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

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

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

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

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

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

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

另一个极端则是过分的限制，就象这个误解。坦白说，任何人都完全可能相信它，我不会有丝毫惊讶。

无数的人问过我这个问题，所以它也进入了“十大误解”之列。如果你觉得这种观点实在天真幼稚，跳过这一部分吧。

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

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

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