反模式作为一种新视角模式，在表述和指导开发上与传统设计模式不同，他先提出模式的反面案例，而后在给出重构方案，这在指导开发人员（尤其是新手）不无裨益。本系列笔记为个人学习总结，也希望没有接触过反模式的朋友们一起学习进步。

正文：

1.   胖球产生的原因：

胖球反模式本身是很简单，但可能由于疏忽，后期没加以控制，系统急于上线等等原因而出现了。

胖球反模式通过描述一个或几个类不断的膨胀，以至吞食掉整个面向对象架构。一般胖球的出现是由于一个类垄断了处理过程，而其他的类只是数据的封装体。

虽然OOA&D 提出了很久，但有些人的思维还停留在过程式的设计上，他们习惯把过程和数据分开，而不是OO中把融合了方法和数据的对象进行职责分割。胖球可能是需求分析不当的结果，也可能是系统不断演进，迭代，新功能和新人员的加入而使部分构件异常庞大而没有进行有效的职责分割，于是某个类成了构件或整个系统的主宰。

总的来说，出现此种问题的原因主要是缺乏面向对象架构，缺乏对架构的实施和干预以及过程式需求的错误引导。

2.   症状和后果：

（1）           单个类拥有大量的属性或操作。

（2）           单个类中封装了异类的、不相关的属性和操作集。

（3）           单个控制器类和几个简单的数据对象联系在一起。

（4）           缺乏面向对象的设计，一个控制器类几乎封装了所有的应用功能。

（5）           控制器类通常过于复杂，无法复用和测试。

（6）           把这么个大类加载如内存中的代价可能会很高。

3.   重构方案：

胖球重构的方法很简单，就是把一些行为重新分配到某些封装了数据的对象上，并对对象之间的关系从新调整（构件和连接件关系调整）。

（1）         确定代表契约的关系操作和属性集合，也就是把相关的属性和方法归类。

（2）         寻找这些根据契约的到了集合的“自然的家”，并把它们迁移过去。

（3）         移除所有的“远耦合”或者说冗余的、间接的联系。

（4）         最后，移除所有的瞬时联系。

总之，我们把一个控制器类变成了一个协调器类，让开始的数据类扩充一些处理逻辑，数据类在协调类的指导下进行操作，这也只是职责的迁移。

胖球反模式有两种形式为行为形式和数据形式，所谓行为形式及所有的处理过程都包含在一个对象中，它与系统中的大多数对象进行交互；数据形式的对象则包含的数据被系统的大部分其他对象所使用。

本文转自BlogJava 新浪blog的博客，原文链接：反模式读书笔记之胖球（—），如需转载请自行联系原博主。