【IT168 技术文章】设计模式对软件开发来说很重要，这一点从它在技术贸易新闻中所占的数量就可见一斑。不过，鉴于其在开发过程中的实用性，设计模式只解决了问题的一半。反模式 ― 描述“对产生绝对负面结果的问题的一种常用解决方案” ― 旨在通过向 Java 程序员展示如何避免常见的 Java 陷阱来解决问题的另一半。

　　使用设计模式重复成功策略

　　我在观察周界瀑布上的漂流时，想起了我所了解的事情。从和别人的谈话中，我了解到所有成功的漂流都是从第三个狭缝的右侧过去的，而且我必须快速地冲过急流，以避免碰上瀑布下浅水上面的石块。这些经验增强了我的信心，我不再理会旋涡的危险，冲进了急流的主干道。

　　虽然我在这些模式的术语中并没有考虑到这一点，我还是在使用设计模式。我将自己的策略建立在那些在我之前成功地通过急流的漂流者的经验之上。设计模式给予我信心，使我能够通过一个原本超越我技能水平之上的急流。我经常将这些相同的原理应用到编程和体系结构中;您可以通过观察一个策略反复的成功结果来学着解决给定的问题。有了设计模式，结果是肯定的。您可以利用自己的经验、观摩导师，或是从书上学习专家是如何做的。

　　我们的编程技巧中很多最重要的先进之处就是来自于设计模式。模型-视图-控制器(Model-View-Controller)模式指导我们有效地分割代码，在用户接口和模型之间定义一个良好的边界。发布-订阅(Publish-Subscribe)设计模式指导我们如何在不广播事件的情况下管理它们。其它的设计模式对各种 Java 框架产生了深远影响：用于远程通信的代理 EJB 接口、集合类、Swing 框架和很多其它框架。

　　我非常喜欢构建可重复过程。从这一点来讲，设计模式可以提供很多好处。设计模式强迫您考虑将问题分割成分立的子问题，其中有一些可以利用可重复解决方案来解决。设计模式还强迫您考虑如何正式地表示和传达设计经验，从而使其它人可以利用您的成果。

　　但是设计模式还不是足够的。如果您将编程问题想象成一个必须穿过的地区，那么设计模式最多只是一张局部地图。毕竟，如果已经存在一个完美的解决方案可以满足您的需求，您可能就会直接去买，而不是自己构建了。此外，随着支持的软件不断发展，基础结构 ― 地图上已有的道路 ― 也在迅速地改变。局部地图可以指引您避开某些危险，但不是所有危险。您将必须在地图之外的地区冒险，才能到达目的地。那么，如果迷失了方向，您会怎么做呢?

　　使用反模式避免落入痛苦的陷阱

　　我在急流中调整方向时，水流将我推向左边。橡皮艇漂流者必须洞悉高难度急流中的危险之处，我在这点上完成了要求。我知道在我之前有一些漂流者漂到左边并翻了船，而且我已经考虑过，并在脑海中练习了解决此问题的方法。经过此番准备，我奋力地划浆，将橡皮艇恢复到原来的方向。现在我有了一步一步战胜困难的机会。

　　下面是在反模式中考虑这个问题的方式：我从一个很难的问题开始。根据其它成功的解决方案，我选择一个计划：我的设计模式。我的计划出了问题，但我有所准备，通过在我的急流中分析其它失败的漂流作出响应：我在使用反模式。因为我有所准备，所以看出了问题，并调整我的方法以回到正途：我在重构。在高难度的橡皮艇漂流和编程中，从自己的错误中学习都是很有价值的，但也很痛苦。我更宁愿从别人的错误中学习。使用这种方法，我就能够试着解决通常远远超越我能力范围的问题了。

　　Antipatterns: Refactoring Software, Architectures, and Projects in Crisis一书的作者这样定义了反模式：

　　反模式是描述对产生绝对负面结果的问题的一种常用解决方案的字面形式。

　　这里的关键词是：

　　字面形式：反模式是问题的描述，而不是代码的描述。这非常重要，因为我们可以迅速和有效地传递消息，而客户可以迅速地理解。

　　常用：如果它不是模式，那它就不是反模式。您必须建立几个不同的运行较差的行为实例，最好是在不同的环境中，这样才能使错误上升到反模式的级别。

　　负面结果：设计必须有可以观察的、负面的效应。

　　最著名的反模式 Y2K 向我们展示了这个激动人心的新领域的危机和出路。回想起以前，成千上万的开发者将日期编码成两位数字而不是四位数字，错误地比较这些数字就会导致数以万计的错误。很多杰出的研究者都预言这个问题将会泛滥成灾，但是经过人们对问题的深入研究，新的标识和重构技术已经很有效地修正了代码，以至于很少有人会碰到预言中那么多的问题。反模式类似于设计模式，是重复使用的解决方案。区别在于反模式有负面结果。当您为反模式做文档时，您将希望获取至少下面这些元素：

　　名称：有时候反模式可能已经有一个或多个非正式的名称，这是由开发社区给出的。其它情况下，您就会希望自己选择一个名称。这个名称应该具有描述性，而且要简单。

　　问题：问题描述了反模式有缺陷的解决方案，以及驱使开发者走向有缺陷的解决方案的推动因素。这个描述指导其他人如何找到问题。

　　重构的解决方案：反模式有用的范围是：可以帮助我们从陷阱中解脱出来，或者完全避免这些陷阱。重构的解决方案是指导其它人如何修正问题的指南。

　　其它成功使用反模式的行业

　　很多其它行业 ― 最值得注意的是制造业 ― 使用某种形式的反模式，通常都是与设计模式相结合使用。当前的制造业者不遗余力地效仿其它同行成功的过程改进。例如即时(Just-in-Time)“设计模式”。即时制造是一种过程，它允许用减少库存和快速修正来解决质量问题，从而提高质量。过程中每个连续的步骤都使用由前一步即时递交的装配件。所有主要的汽车制造业者现在都使用这种技术。制造业者还采用了其它设计模式进行装配组织、测试以及数据收集。最好的制造业者并没有在这里停滞不前。他们还认识到对发现系统过程故障的需求。类似于 Zero Defects 和 Quality Circles 这样的程序让车间中的蓝领工人周期性地花一点时间讨论系统过程问题，以及如何尽可能地防止问题出现。一般的程序都能够为雇主节省大量维护所需的时间。行业中反模式的其它示例还包括：

　　保健行业，研究者在这里查找和发布不良的饮食习惯，然后好的医生会使用这些信息来指导病人如何改变引起疾病的根源，而不仅仅是症状。

　　法律执行，警官在这里与社区合作，确定和预防治安不良地区中的犯罪根源。这些程序可以显著地减少毒品服用和暴力犯罪的情况。

　　出版行业，经过十多年对作者的忽略之后，最成功的出版商再次与作者以紧密地伙伴关系相互合作。这种伙伴关系有助于作者确定和改正不良写作习惯，从而写出更好的书。最成功的技术读物出版商就使用这种方法，而其它出版商正在效仿。

　　Java 语言中反模式的示例

　　如果反模式在其它行业中都很成功的话，那么程序员能不能也从中受益呢?我相信程序员能得到的还不止这么多。作为程序员，您如果想成功，只需要快速地识别出常见的陷阱就可以了。软件开发所使用的是一套难以置信的相反的工具、语言、方法和策略。让我们回头想想地图的类推。不同情况下的问题稍有不同。您需要具有归纳知识并将其转用到其它情况的能力，这样才能成功。设计模式倾向于定位在特定问题域上，而反模式就可以更具普遍性。实际上，您可能犯的很多错误以前就已经存在了。反模式有助于帮您在开发周期的早期识别出更多此类错误。如果您和多数程序员一样，那么花一点时间去理解当前环境中的陷阱可以为您节省大量时间和工作。Java 语言的发展向我们展示了很多有关错误的示例，这些错误是我们从其它编程的发展中借鉴的。

　　早期的 EJB 实体 bean 实现慢如蜗牛，一部分原因是通信开销过于高昂。 经过一段时间之后，人们开始认识到其中一个显著问题是往返旅程。我们最终学会了使用类似于虚包的修正方法来重构这些解决方案。其它开发者在 EJB 组件问世很久之前就碰到了这个问题。早期个人电脑上的数据库一直为性能问题所困扰，直到管理员学会了使用存储过程将多个数据库通信巩固为一体。早期的分布式系统开发者也发现了相同的问题，然后发布了虚包解决方案。

　　常见的 Java 反模式的另一个示例是魔法 Servlet。这个非常基础的反模式困扰了很多相对高级的客户。在这个反模式中，一个单独的 servlet 将处理视图、模型以及控制器逻辑。这样的设计使得维护几乎不可能实现，因为无论视图何时改变，您都必须改变模型逻辑，反之亦然。魔法 Servlet 也有比 Java 语言更早的渊源。此问题最常见的示例其实发生在 Visual Basic 中，程序员在 Visual Basic 中经常会向一个单独的控件(如按钮)附加 10K 大小的脚本。

　　这些问题只是涉及到表面。在每个新的领域中，Java 开发者都会重新发现一些旧的错误，而这些错误具有某种规律性。如果我们抱着扫清障碍的目的研究这些陷阱，就一定会免受一些痛苦。

　　使用反模式过程

　　希望我已经使您相信反模式是值得注意的。那么要将反模式与您每天的例行工作相结合，您又可以做些什么呢?图 1 展示了一个过程的大体步骤，它可以帮助您识别和解决反模式。我在 Bitter Java一书中(请参考 参考资料)更详细地讨论了这些问题。

　　图 1. 一个基本的反模式过程中的步骤

　　识别问题。在 Java 编程中，问题可能是错误、性能问题、难于维护的类，或是不断增大的内存占用量。

　　建立模式。如果您是一名软件工程专业的学生，那么您就会知道，随着您不断深入开发周期，修正一个错误的开销将呈指数上升。当您建立问题的模式时，您就给了自己在开发周期的更早阶段识别和修正更多问题的机会，您的获得也将数以倍计。使这个价值链向上移动的关键就在于建立模式，然后尽可能广泛地根据反模式操作。

　　重构代码。在这一步中，您将重构导致问题的代码。这一步是一个简单的错误修正，它适用于您迄今为止识别出的所有问题实例。您应该花时间去做一个完整的修正，而不是仅仅打一个补丁了事，如果错误可能会出现在同一位置，您还应该添加文档。您还会希望对各个步骤作出文档，从而将解决方案分发给其它人。

　　宣传解决方案。您在这里确保碰到问题的其它人懂得如何修正问题，并确保可能碰到陷阱的其它人知道要避开它。发布反模式可以更广泛地传播反模式的好处。

　　修正过程。您在这里构建一个隔开反模式保护性的屏障。修正可以采用很多不同的方式。改进测试案例可以快速地识别衰退。修正每日过程或通信渠道可以在问题发生之前预防它们。补充编码标准几乎能够消除某些类型的编码错误，如关于放置花括号或注释的错误。

　　这些步骤采用的方法是从特定到一般。您找到错误，然后建立模式、修正错误，最后修正过程。将其中某些步骤与您的日常例行工作相结合可以使您成为更好的程序员。但是，请不要在这里停下来。请利用您的反模式知识来修正过程，继续使价值链向上移动，并让您整个公司的程序员都变得更棒。您还可以发布反模式帮助您甚至不认识的程序员。如果您是一名程序员，并且是设计模式的爱好者，我保证您会发现反模式能够提供的不止这些。