http://35java.com/zhibo/forum.php?mod=viewthread&tid=111&extra=page%3D3
在东田纳西州寒冷的一天，我的橡皮艇摇摆不定地停靠在一个十六英尺高的瀑布顶上，这个瀑布名叫州界瀑布（State Line Falls）。这条急流因为经常吞噬小船和人而臭名昭著。从顶上望过去，急流拐角处没有什么危险的迹象，但是我知道。几天以来，我在清醒的每一刻心中都记得旅行指南中对它的描述。五个卡车般大小的石块形成了四道狭缝。我只能在穿过急流的前几秒看到整个瀑布。对于这四道狭缝中的三个来说，您的岳母要穿过去可能会太费力、太危险，它们因此而闻名。急流劈波斩浪地冲过第四道“友好的”狭缝，加速前行，拍打在凹凸不平石块上。我的职业是程序员，还是两个孩子的父亲，也算一个中等技能的橡皮艇漂流爱好者。我连穿过旅游手册中作为“旁注”而描述的五级瀑布的本事都没有。我在这里到底要干什么？
作为程序员的我也多次问过自己相同的问题。在我准备解决一个不熟悉的问题时，如果进度压力越来越大，而且失败将带来可怕的后果，我也曾踏上一个类似的悬崖边缘，这种情况不胜枚举。在本文中，我将讨论一种能够帮助程序员走出此类困境的工具： 反模式。我还会指出反模式能够以何种方式补充您的设计模式学习。如果您经常访问 developerWorks，您就会看到上面介绍了很多设计模式，也会看到对其内在价值的争论。可是，虽然 Eric Allen 的关于错误模式的文章（请参阅 参考资料）对它们的有效性给了您一个暗示，但您对反模式可能还不会有相同的认识。不只是您会这么想。几年来，开发者已经发布了很多关于设计模式描述很深入的书和文章，但有关反模式的相同社区却少之又少。我撰写本文的目的在于向您说明，反模式是设计模式的一个必要的和补充的伴侣。
使用设计模式重复成功策略
我在观察周界瀑布上的漂流时，想起了我所了解的事情。从和别人的谈话中，我了解到所有成功的漂流都是从第三个狭缝的右侧过去的，而且我必须快速地冲过急流，以避免碰上瀑布下浅水上面的石块。这些经验增强了我的信心，我不再理会旋涡的危险，冲进了急流的主干道。
虽然我在这些模式的术语中并没有考虑到这一点，我还是在使用设计模式。我将自己的策略建立在那些在我之前成功地通过急流的漂流者的经验之上。设计模式给予我信心，使我能够通过一个原本超越我技能水平之上的急流。我经常将这些相同的原理应用到编程和体系结构中；您可以通过观察一个策略反复的成功结果来学着解决给定的问题。有了设计模式，结果是肯定的。您可以利用自己的经验、观摩导师，或是从书上学习专家是如何做的。
我们的编程技巧中很多最重要的先进之处就是来自于设计模式。模型-视图-控制器（Model-View-Controller）模式指导我们有效地分割代码，在用户接口和模型之间定义一个良好的边界。发布-订阅（Publish-Subscribe）设计模式指导我们如何在不广播事件的情况下管理它们。其它的设计模式对各种 Java 框架产生了深远影响：用于远程通信的代理 EJB 接口、集合类、Swing 框架和很多其它框架。
我非常喜欢构建可重复过程。从这一点来讲，设计模式可以提供很多好处。设计模式强迫您考虑将问题分割成分立的子问题，其中有一些可以利用可重复解决方案来解决。设计模式还强迫您考虑如何正式地表示和传达设计经验，从而使其它人可以利用您的成果。
但是设计模式还不是足够的。如果您将编程问题想象成一个必须穿过的地区，那么设计模式最多只是一张局部地图。毕竟，如果已经存在一个完美的解决方案可以满足您的需求，您可能就会直接去买，而不是自己构建了。此外，随着支持的软件不断发展，基础结构 ― 地图上已有的道路 ― 也在迅速地改变。局部地图可以指引您避开某些危险，但不是所有危险。您将必须在地图之外的地区冒险，才能到达目的地。那么，如果迷失了方向，您会怎么做呢？
