面向对象的思考过程（原书第5版）

10.4　反模式

设计模式是从有益的经验中总结出来的，反模式则来自失败的经验。大多数软件项目最终不成功的原因都会被记载下来，最终总结为反模式。事实上，Johnny Johnson的文章“Creating Chaos”指出，至少三分之一的项目最终都会被彻底取消。显而易见大多数失败的原因都是错误的设计决策导致的。

设计模式都是为了尽力解决一个特定类型的问题，而反模式则恰恰相反。换句话说反模式反映了解决一个问题时失败的经验。简单来说，设计模式是一种好的设计实践，反模式则是一种需要避免的实践。

Andrew Koenig在1995年11月的C++ Report中描述了两种类型的反模式：

·一种是描述了解决问题的糟糕的解决方案，导致情形向坏的方向发展。

·另一种是描述了如何使用好的解决方案来摆脱糟糕的情形。

很多人相信反模式比设计模式更有用。这是因为反模式可用来解决他们已经遇到的问题。这会导致人们停止于对问题根源的分析。通过数据分析可以得出最初的设计（可能是一种设计模式）为什么不成功。失败的方案会暴露出反模式。因此，反模式有点像事后诸葛亮。

例如，在文章“Reuse Patterns and Antipatterns”中，Scott Ambler识别了一个叫作健壮的组件的模式，并且进行了如下定义：

“健壮的组件是指该组件拥有详尽的文档，它不是为了满足具体项目的需求，而是具有通用性，并且经过完整测试，而且有几个示例来展示如何使用该组件。如果组件满足以上几点，那么它更容易被重用。健壮的组件是更容易理解和使用的项目”。

不过当声明了一个可重用的方案后，很可能在大部分场景下没人会重用它。因此，为了阐述反模式，他写道：

“除了原始的开发人员，其他人员也必须审查该组件。如果其他人员也对该组件感兴趣，那么必须保证重新设计该组件为健壮的组件。” ...