AntiPatterns —— The Blob

----------------------------------------------------------------------------------------------

反模式名称：The Blob

别名：Winnebago（温内贝戈人）[Akroyd 1996]和The God Class（上帝类）[Riel 1996]

最常见规模：应用层

重构方案名称：Refactoring of Responsibilities（职责重构）

重构方案类型：软件

根源：懒惰、匆忙

不平衡的力量：功能管理、性能管理、复杂性管理

轶事证据：“这个类确实就是我们架构的心脏。”

----------------------------------------------------------------------------------------------

症状和后果

  ● 单个类拥有大量的属性或操作，或两者都有。具有60个以上属性和操作的类通常就表示The Blob的存在。

  ● 在单个类中封装了异类的、不相关的属性和操作集。属性和操作在总体上缺乏相关性是The Blob的典型特征。

  ● 单个控制器类与多个简单的数据对象类联系在一起。

  ● 缺乏面向对象设计。系统就是The Blob类中的程序主循环与相对被动的数据对象联系在一起。单个控制器类往往和过程式编程中的主程序一样，几乎封装了整个应用的所有功能。

  ● 迁移遗留设计时未正确重构到面向对象架构。

  ● The Blob影响了面向对象设计的内在优势。例如，它限制了在不影响其他封装对象的条件下对系统进行修改的能力。对The Blob类的修改会对它的封装内的大量软件产生影响。修改系统中的其他对象也可能会影响到The Blob类中的软件。

  ● The Blob类通常过于复杂，无法复用和测试。为了The Blob中的功能子集而试图复用它往往是低效的，或者会产生过多的复杂性。

  ● 把The Blob类载入到内存中的代价可能会相当高，会使用过多的资源，即使只需要其中的简单操作时也是如此。

典型原因

  ● 缺乏面向对象架构。设计者可能没有充分理解面向对象的原则。也可能是开发团队缺乏适当的抽象技能。

  ● 缺乏（任何形式的）架构。对系统构件、它们之间的交互，以及选中的编程语言的特定用途缺乏定义。这使得程序以专用的方式发展，因为编程语言被用于实现它们的本来意图之外的目的。

  ● 缺乏对架构的实施。有时即使规划了一个合理的架构，也会意外地出现这种反模式。它可能是在开发过程中没有进行充分的架构性审查的结果。尤其是新接触面向对象的开发团队尤其容易出现这个问题。

  ● 干预过少。在迭代式项目中，开发人员倾向于给已有的可工作类一点一点增加功能，而不是增加新类或者为了更有效地分配职责而修改类层次关系。

  ● 需求说明灾难。有些时候，The Blob来源于说明需求的方式。如果系统需求规定了一个过程式解决方案，在需求分析阶段可能就会在架构方面做出难以改变的承诺。把定义系统架构作为需求分析工作的一部分通常是不恰当的做法，往往会导致The Blob反模式，甚至可能会更糟。

重构方案

和本节的大多数反模式一样，解决方案中包含了一个重构形式。关键是把一些行为从The Blob中移出去。合适的做法也许是把一些行为重新分配到某些封装的数据对象，让它们起更多的作用，而The Blob类不再那么复杂。职责重构的方法如下所述：

（1）根据契约确定或分类相关的属性和操作。这些契约本身应该是相互关联的，直接与整体系统中某个共同的焦点、行为或功能相联系。

（2）第二步是寻找这些根据契约得到的功能集合的“自然的家”，并把它们迁移过去。

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

（4）接下来，如果合适的话，我们把到派生类的联系迁移到一个共同的基类。

（5）最后，我们移除所有的瞬时关系，用适当的属性类型说明和操作参数来替代它们。