JAVA面向对象设计过程中的反面模式

 

我们看过许许多设计模式的理论，实际工作过程中也或多或少的使用过设计模式，不同类型设计模式适用于不同的应用场合，但如果设计模式使用不当，不但无法帮助产品提升，反而会导致日后的重蹈覆辙。因此，我们有必要了解在日常工作中经常错误使用模式的场合，通常将这些内容称之为反面模式（anti-pattern）。

   反模式（anti-pattern）是指在实践中经常出现，会导致效率低下的有待优化的设计模式。反面模式的类型多种多样，其中包含项目管理、团队管理、分析方式、编程、方法学、测试、配置管理等多个方面，今天主要介绍面向对象设计过程中常见反面模式：

      1.基类（BaseBean）：继承一个工具类，而不是代理它

      这种对象设计错误在开发过程中是非常常见的，通常造成这种设计错误是为了使用方便，继承一个工具类，可以非常方便的在对象中使用工具类提供的方法，但这种设计会造成了对象意义混乱，通常只有在分类学角度上具有意义时，才使用继承，从里氏替换原则考虑，一个工具类必定有自己特定的行为特征，一个封装了逻辑的对象，不可能是工具类型的一中，因此，不要从工具类继承，如果要使用或者扩展工具类服务，使用代理模式是较好的选择。

     2.调用父类（Call super）：需要子类调用父类中被子类重载的方法

     在面向对象设计中，子类具有拓展超类的责任，而不是具有置换掉或注销掉超类的责任。如果子类需要大量的置换掉超类的行为，那么这个子类不应当成为这个超类的子类。如果子类需要调用父类中被子类重载的方法，这是非常不合理的，子类应当具备父类的所有特性，同时是对父类的扩展。

     3.不羁的对象（Objectorgy）：没有成功封装对象，外部可以不受限制地访问它的内部

      这也是开发过程中的常见现象，通常是为了减少代码量，例如对象属性均使用public修饰符，这样可以减少编写对象类时的访问代码，但这也使得对象封装没有了意义。

     4.幽灵（Poltergeists）：指这样一些对象，它们唯一的作用就是把信息传给其它对象

     如果在设计的时候已经确定一个对象向另外一个对象传送的信息内容，使用对象封装传送是很不好的，这种对象作用非常单一，也是没必要的，和幽灵一样！

     5.顺序耦合（Sequentialcoupling）：指这样一些对象，它们的方法必须要按某种特定顺序调用

   如果方法需要按特定顺序调用，良好的对象设计应当把这些方法顺序调用的逻辑封装在对象内部，而不是要求外包调用时按照特定的顺序，这极容易造成对象使用错误。

    6.单例爱好者（Singletonitis）：滥用单例（singleton）模式

   单例模式的意思就是确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，通常是为了避免当实例存在多个时可能会造成程序逻辑错误的问题。滥用单例模式会造成许多问题，例如对象并发访问等。

    8.又TMD来一层（Yet Another FuckingLayer）：向程序中添加不必要的层次结构、库或是框架。

    这种情况在构建技术框架时很常见，JAVA有众多的开源框架或者库，因此，在构建技术框架初期，经常把许多没必要的库、框架引入。这对开发及最终目标系统都没好处，会导致整个系统技术架构混乱及运行时的性能问题。

    9.唷唷问题（Yo-yo problem）：一个结构（例如继承）因为过度分裂而变得难于理解

    对象设计时，没有意义的分裂对象是个灾难，除了导致最终对象结构难以理解外没有任何好处。

    10.对象粪池（Object cesspool）：复用那些不满足复用条件的对象。

      对不满足复用条件的对象复用，本身就是个灾难！

    11.空子类的错误（Empty subclassfailure）：创建不能通过“空子类测试”的类，因为它和直接从它继承而来没有做其它任何修改的子类表现得不同

      创建了一个子类，该子类不具备父类的特征，从面向对象设计而言，这不符合继承。

    12.上帝对象（God object）：在设计的单一部分（某个类）集中了过多的功能

    合适的对象行为在面向对象设计过程中非常重要，在单一部分集中了过多的功能会导致后续的类维护变得极为困难。

 

更多反面模式，参见：

http://zh.wikipedia.org/wiki/%E5%8F%8D%E9%9D%A2%E6%A8%A1%E5%BC%8F#.E7.BC.96.E7.A8.8B.E4.B8.8A.E7.9A.84.E5.8F.8D.E6.A8.A1.E5.BC.8F