模式与反模式

“示例不是另一种学习的方法，而是学习的唯一方法。”——阿尔贝特·爱因斯坦

模式和模式语言捕获并正式地将良好设计和基于经验的最佳实践系统化，以供其他人员对其进行重用。它们成功而清楚地表述了常见问题及其解决方案。总的来说，常见概念、描述这些概念的词汇以及将其联系在一起的语言是所有采用这些设计和实践的学科和领域的基础。

Christopher Alexander 关于建筑物和城市设计的研究通常被认为是基于模式的思维最早的成果（请参阅参考资料）。他提出了术语“模式语言”，以此代表他认为人类进行设计的能力和使用语言的能力都是天生的这一信念。

很多学科都在使用模式和模式语言的概念，包括从生理学和流程到项目管理和软件工程等领域。在 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides（经常将他们称为 Gang of Four）的“Design Patterns: Elements of Reusable Object-Oriented Software”一书出版后，软件设计模式得到了广泛的认可和使用。

软件社区目前正使用模式来解决在软件生命周期中遇到的不断重复的问题，包括软件体系结构和设计，以及近来的软件开发流程和拓扑。这些模式全面捕获了一个知识体系，以标识我们对可以实现设计良好的软件解决方案的结构和机制的理解。

模式经常被定义为“泛型化的、命名的问题到解决方案的映射”。它捕获在特定环境中重复出现的问题的成功解决方案。

通常使用与表 1“模式模板”中描述的模板类似的模板来记录软件模式。

软件模式提供了一个在架构师和设计人员中捕获知识和经验的机制。它们提供了一种公共语言，可促进对其他地方成功应用的方法的重用，从而为软件项目带来以下方面的好处：风险更低、质量更好且交付时间更短。

而在另一方面，反模式则记录出现错误的情况。对数百个软件开发项目的各种调查勿庸置疑地证明了软件开发会出现错误（实际上经常是这样）。研究表明每六个项目中就有五个会不成功：交付远远超过预期预算、严重滞后或被取消。这就表明可能（至少）值得投入精力研究一下老是失败而很少成功的原因（注意 Bitter Java 的作者 Bruce Tate 在他的 developerWorks 文章中说明了为什么反模式是设计模式的必要和互补的同伴——有关更多信息，请参阅参考资料）。

应该对这些重复失败的软件开发项目或“反解决方案”加以研究，以收集关于出现了什么问题以及为什么会这样的有用知识。很显然，只对错误的原因进行分类并不一定非常有用，而还应研究如何加以避免以及出现时如何恢复。系统化后，这个知识集合可以提供软件模型的有价值的扩展（归类为反模式）。

反模式 使用非常频繁，但主要是问题的无效解决方案。这个术语最初是用于指示设计模式出现了错误。与模式类似，反模式的使用也扩展到了软件开发的各个阶段，并深入到了其他领域中。反模式记录常见的对效率有负面影响的重复解决方案。它们通常捕获重构解决方案描述，说明如何更改反模式，以得到更为稳定的解决方案。反模式通常使用模板进行描述，在其中标识症状、结果、根本原因和可能的解决方案。尽管与模式相比，反模式的研究并不很广泛，相关文档也不多，但软件领域对其中一些具有引人瞩目的反模式（如分析停顿、Blob、意大利面条式代码和“烟囱”系统）已耳熟能详。表 2 提供了一些这些示例的概述，这些示例均摘自 Brown 等的关于反模式的书中（有关更多信息，请参阅参考资料部分）。

反模式为什么重要？反模式是用于防止问题的工具，可在问题出现之前对其进行标识，并能提供关于如何防止其发生的知识。通过将错误原因正式地系统化，我们可以更容易对其加以理解。一旦出现问题，反模式可以提供帮助，能说明如何从其进行恢复。

1 2 3 4 5 下一页>>