误解之五:“模式可以保证软件的复用性、更高的生产力、世界的和平⋯⋯”
道理很简单,模式什么都不保证。它们甚至有可能无法给你带来利益。在创造新事物的过程中,模式无法取代人的位置。它们只是带来一种希望,有可能让一个缺乏经验的、甚至是未入门的,但是有能力、有创造性的人尽快获得设计的能力。
人们经常说:好的模式会让读者有“啊!”的回应。实际上,只有当模式恰好拨动了读者的某一根心
弦时,他们才会有这样的反应。如果没有,模式就只象森林里普通的一棵树。因此,什么是好的模式?不管它写得有多好,如果不能引起读者的共鸣,它又怎能算是好的模式?
模式只是开发者的工具箱中的另一件工具,对模式寄以过高的期望只会适得其反。准备充分,然后做最坏的打算——这就是防止受骗、消除对抗最好的方法。
误解之六:“模式可以‘生成’整个软件体系”
这个误解与上一个有点相似,不过侵略性稍微少些。
每过一段时间,模式论坛上就会讨论一次模式的生成能力。按照我的理解,“生成能力”是指模式创
建最终行为的能力。很多人认为,模式可以帮助读者解决模式本身没有明确提出的问题。我读过的一些书里也有同样的观点。
对于我来说,“生成能力”的关键是模式的可传授性——约束及其解决,或者对于效果的讨论。在你
定义、精炼一个体系结构时,这些观察是特别有用的。但是模式本身并不制造任何东西——任何东西都是由人来制造的。而且,模式不可能覆盖体系结构的每个方面。给我任何一个有实际价值的设计,我都能找出其中模式没有涉及的设计问题。也许这些问题不常见、不具可重复性,或者只是还没有以模式的形式记录下来。不管怎样,你都必须负责填补模式之间的空白——用你自己的创造性。
误解之七:“模式是针对(面向对象)设计或实现的”
另一个极端则是过分的限制,就象这个误解。坦白说,任何人都完全可能相信它,我不会有丝毫惊讶。
无数的人问过我这个问题,所以它也进入了“十大误解”之列。如果你觉得这种观点实在天真幼稚,跳过这一部分吧。
如果模式不能记述专家的经验,那它们就什么都不是。对于模式的作者来说,任何形式的专家经验都是可记载的。当然,在面向对象软件设计中有值得记载的经验,但是在非面向对象设计和分析、维护、测试、文档、组织结构⋯⋯这些方面也同样有值得记载的经验。现在,不同领域中的模式开始浮出水面。至少已经有两本关于分析模式的书[Fowler97, Hay96],并且每次PLoP 大会都会收到新的模式类型。(特别有趣的是1996 年的PLoP 大会甚至关注了音乐作曲的模式!)
和大多数的误解一样,这个误解也是有原因的。看看人们用来描述模式的格式,有两种基本的风格:描述高层结构的GoF 风格(用于《设计模式》中);接近文学的Christopher Alexander 风格——叙述性的,尽量少的结构图。由于已经用模式描述了面向对象设计之外的东西,所以我现在认识到GoF 风格造成的偏差。对于我研究过的某些领域的专家经验,这种风格根本无法描述。为什么结构图看上去总是让人联想到C++?对于音乐作曲的模式,“实现”应该是什么?“协作”部分真的有意义吗?
很明显,一种格式不能适应所有的需求。比较具有普遍意义的是模式的概念:模式是记载并传达专家经验的工具——不论是哪个领域的专家经验。