误解之六：“模式可以‘生成’整个软件体系”
这个误解与上一个有点相似，不过侵略性稍微少些。
每过一段时间，模式论坛上就会讨论一次模式的生成能力。按照我的理解，“生成能力”是指模式创建最终行为的能力。很多人认为，模式可以帮助读者解决模式本身没有明确提出的问题。我读过的一些书里也有同样的观点。
对于我来说，“生成能力”的关键是模式的可传授性——约束及其解决，或者对于效果的讨论。在你定义、精炼一个体系结构时，这些观察是特别有用的。但是模式本身并不制造任何东西——任何东西都是由人来制造的。而且，模式不可能覆盖体系结构的每个方面。给我任何一个有实际价值的设计，我都能找出其中模式没有涉及的设计问题。也许这些问题不常见、不具可重复性，或者只是还没有以模式的形式记录下来。不管怎样，你都必须负责填补模式之间的空白——用你自己的创造性。
误解之七：“模式是针对(面向对象)设计或实现的”
另一个极端则是过分的限制，就象这个误解。坦白说，任何人都完全可能相信它，我不会有丝毫惊讶。无数的人问过我这个问题，所以它也进入了“十大误解”之列。如果你觉得这种观点实在天真幼稚，跳过这一部分吧。
如果模式不能记述专家的经验，那它们就什么都不是。对于模式的作者来说，任何形式的专家经验都是可记载的。当然，在面向对象软件设计中有值得记载的经验，但是在非面向对象设计和分析、维护、测试、文档、组织结构……这些方面也同样有值得记载的经验。现在，不同领域中的模式开始浮出水面。至少已经有两本关于分析模式的书[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]。
文章来源于领测软件测试网 https://www.ltesting.net/
