Java应用中的反模式开发介绍
来源：网络 更新时间：2014-11-27
设计模式（designpattern）为我们提供了一条途径，使我们能够进行简洁明了地沟通，以得到期望的软件经验；反模式与此类似，只不过它是用于沟通那些不合乎需求的经验的--下面是一些可以帮助你起步的通常遇到的反模式。
反模式是一种典型的、糟糕的设计；换句话说，它是设计模式的对立面--设计模式提出的是良好的设计。在某种意义上讲，反模式表现的是糟糕的解决方案，它让相关人员更容易理解根本的问题和问题之间的因果关系。尽管了解设计模式很重要，但是我相信理解反模式也是一样重要的--我们应该理解反模式。
我们来证明一下自己的观点。软件世界是围绕应用程序的维护来"运行"的。当然，每个软件产品的生命周期都是从构造的时候开始的，但是在开始大量生产以后，就需要维护了。根据开发小组的技巧，产品可能拥有"良好的"或"糟糕的"设计，其中的"良好"或"糟糕"是对应于一定的环境中，因为一种良好的设计如果应用在错误的环境中也可能成为一种反模式。例如，在单应用程序（single-application）服务器环境中使用Singleton是恰当的，但是在群集应用程序（clustered-application）服务器环境中，如果它没有被正确地处理好，就会产生很多问题。与正面的设计模式形成对比的是，反模式引出的是负面的解决方案或以前的方法（去年的解决方案在今年就可能是反模式了），这可能是由于小组成员缺乏足够的信息，或者在实现设计或解决问题方面作出了糟糕的判断。
在产品开始生产并进入维护模式之后，真正的问题才开始显现。一个从未参与产品开发的从事维护工作的开发者可能给项目引入"糟糕的设计"元素。但是如果这种糟糕的实践被编写为反模式"法典"，就可以预先提醒开发者，避免最普通的缺陷，就像设计模式"法典"为开发者提供了识别出普通的有用的技术途径一样。根据这种逻辑，反模式是一种值得我们记载的普遍存在的糟糕的设计。
当我们使用J2EE等技术的时候，这种方法的优势尤其明显。J2EE的初始设计哲学强调简单性，但是它的复杂程度已经变得难以置信了。在这种复杂的环境中，模式和反模式同时为软件经理、架构师、设计师和开发者提供了通用的"词典"。
无论在构造模式还是在维护模式中，为了获得成功，我们理解反模式都是必要的。在反模式被记录下来之后，开发者一般可以认识到这些负面的模式，以根除糟糕的设计，改善软件。
本文从软件架构和开发的角度来谈论反模式。接着它提出了在J2EE应用程序的大多数通用层次（用户界面、永续性、EJB等）中普遍存在的反模式。它的全部目标是为这些反模式提供背景知识，并为避免这些问题提供建议。
表1列举了本文中讨论的三种普遍的设计、开发和架构的反模式。
表1：普遍的反模式
领域普通的反模式设计编写具体的类而不是接口在代码中耦合了逻辑（例如日志记录、安全性和缓冲）开发GoldenHammer（金锤）InputKludge（输入杂乱）架构Reinventthewheel（重新发明轮子）Vendorlock-in（厂商的锁定）
普遍的反模式
上表列举的反模式跨越了广阔的开发者领域。
编写具体的类而不是接口
这是一条重要的设计原则，但是却经常被破坏--编写接口而不是具体的类可以提供数不清的优点！你不会被"捆绑"在使用某种特定的实现上，同时可以在运行时改变行为。"接口"这个术语意味着要么是一个Java接口，要么是一个抽象类。只要你应用多态性（polymorphism），应用程序的行为就不会被"锁定"在特定的代码中。请注意，当你知道其行为不会改变的时候，这条规则就不适用了。
编写一个实现的例子如下所示：
Doganimal=newDog();
animal.bark();
作为对比，编写一个接口的例子是：
Animalanimal=getAnimal(Dog.class);
