设计模式和反模式简单介绍

摘要：本文主要讲的是反模式， 反模式（英文：Anti-patterns或pitfalls）, 是指用来解决问题的带有共同性的不良方法。它们已经经过研究并分类，以防止日后重蹈覆辙，并能在研发尚未投产的系统时辨认出来。

 

作为一个资深开发人员，大家都应该听说过设计模式(design pattern)，但是不是所有的人都听说过反模式(anti-pattern)。今天我们就来谈谈后者，何为反模式。

谈反模式之前当然先要谈谈何为设计模式，因为两者是紧密联系在一起的。从我个人的理解认为，设计模式是一种在前人的设计经验上总结出来的对于一些普遍存在的问题提供的通用的解决方案。这些设计模式已经经过了长时间的实际应用和验证，被证实是有效可行的解决方案。通过使用设计模式，我们可以获得以下优势：

1.       开发小组不需要重新设计解决方案来解决已经被前人解决过的问题。如此可以节省很多设计开发时间。

2.       当开发小组讨论设计的时候，使用设计模式可以使大家更好了理解问题所在和解决方案，而且对解决方案有一个比较统一的认知。

3.       设计模式本身已经通过了大量的实际运用和验证，其设计质量和实用价值有很好的保证。

4.       设计模式本身有健全的文档，可以一定程度上简化撰写开发文档。

在开发过程中，使用设计模式对系统/软件开发有很多其他的优点，这里就不一一列举了。一些常用的设计模式包括：单列模式， 工厂模式， 修饰模式， 策略模式， 代理模式等等。有兴趣的朋友可以看下 “四人帮” 的 设计模式这本书 “Design Patterns: Elements of Reusable Object-Oriented Software”， 其他还有大量讨论设计模式的书籍， 比如 “Head First Design Pattern”,  “The Design Patterns Java Workbook” 等等。

简单的谈完了设计模式，我们来谈一下重点，什么是反模式。很多人对反模式有一个理解误区，有人认为反模式是由于将通常使用的设计模式用在了错误的地方，也有人认为反模式只是一种坏习惯。简单的来说，反模式是指在对经常面对的问题经常使用的低效，不良，或者有待优化的设计模式/方法。甚至，反模式也可以是一种错误的开发思想/理念。在这里我举一个最简单的例子：在面向对象设计/编程中，有一条很重要的原则， 单一责任原则(Single responsibility principle)。其中心思想就是对于一个模块，或者一个类来说，这个模块或者这个类应该只对系统/软件的一个功能负责，而且该责任应该被该类完全封装起来。当开发人员需要修改系统的某个功能，这个模块/类是最主要的修改地方。相对应的一个反模式就是上帝类(God Class)，通常来说，这个类里面控制了很多其他的类，同时也依赖其他很多类。整个类不光负责自己的主要单一功能，而且还负责了其他很多功能，包括一些辅助功能。很多维护老程序的开发人员们可能都遇过这种类，一个类里有几千行的代码，有很多功能，但是责任不明确单一。单元测试程序也变复杂无比。维护/修改这个类的时间要远远超出其他类的时间。很多时候，形成这种情况并不是开发人员故意的。很多情况下主要是由于随着系统的年限，需求的变化，项目的资源压力，项目组人员流动，系统结构的变化而导致某些原先小型的，符合单一原则类慢慢的变的臃肿起来。最后当这个类变成了维护的噩梦(特别是原先熟悉的开发人员离职后)，重构该类就变成了一个不容易的工程。

 

同设计模式一样，也有不少的书籍讨论反模式，比如 “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”， “Antipatterns: Identification, Refactoring, and Management”， “J2EE AntiPatterns”，对设计模式和反模式感兴趣的朋友们有空可以读一下。

 

举例：

 

软件膨胀：随着版本的升级，软件越来越消耗系统资源。

反抽象：需要的功能并不暴露给用户，导致用户要在较高层次重新实现一些功能。

万能类︰在一个类的设计中，聚集了太多的函数。

硬编码(Hard Code)：或称写死。在实现某系统用途上设死该系统的运作环境。

超布尔逻辑︰不必要的比较，或是过于抽象的布尔计算。

剪贴编程(Copy-n-paste programming)：宁愿拷贝(并修改)现存代码而非创造通用的解决方案。

 

参考：设计模式和反模式简单介绍

反模式