三、Extract Class (提炼类)

某个类做了应该由两个类做的事。

建立一个新类，将相关的字段和函数从旧类搬移到新类。

动机

你也许听过类似的教诲：一个类应该是一个清楚的抽象，处理一些明确的责任。但是在实际工作中，类会不断成长扩展。你会在这儿加入一些功能，在那儿加一些数据。给某个类添加一项新责任时，你会觉得不值得为这项责任分离出一个单独的类。于是，随着责任的不断增加，这个类会变得过分复杂。很快，你的类就会变成一团乱麻。

另一个往往在开发后期出现的信号是类的子类化方式。如果你发现子类化只影响类的部分特性，或如果你发现某些特性需要以一种方式来子类化，某些特性则需以另一种方式子类化，这就意味你需要分解原来的类。

做法

1、决定如何分解类所负的责任。

2、建立一个新类，用以表现从旧类中分离出来的责任。

3、建立“从旧类访问新类”的连接关系。

? 有可能需要一个双向连接。但是在真正需要它之前，不要建立“从新类通往旧类”的连接。

4、对于你想搬移的每一个字段，运用Move Field搬移之。

5、每次搬移后，编译、测试。

6、使用Move Method将必要函数搬移到新类。新搬移较低层函数（也就是“被其他函数调用”多于“调用其他函数”者），再搬移叫高层函数。

7、每次搬移之后，编译、测试。

8、检查，精简每个类的接口。

? 如果你建立起双向连接，检查是否可以将它改为单向连接。

9、决定是否公开新类。如果你确定需要公开它，就要决定让它成为应用对象还是不可变的值对象。

四、Class(将类内联化)

某个类没有做太多事情。

将这个类的所有特性搬移到另一个类中，然后移除原类。

动机

Inline Class 正好与Extract Class 相反。如果一个类不再承担足够责任，不再有单独存在的理由（这通常是因为此前的重构动作移走了这个类的责任）我就会挑选这一“萎缩类”的最频繁用户（也是个类），以Inline Class 手法将“萎缩类”塞进另一个类中。

做法

1、在目标类身上声明源类的public 协议，并将其中所有函数委托至源类。

? 如果“以一个独立接口表示源类函数”更合适的话，就应该在内联之前先使用Extract Interface 。

2、修改所有源类引用点，改而引用目标类。

? 将源类声明为private，以斩断包之外的所有引用可能。同时修改源类的名称，这便可使编译器帮助你捕捉到所有对于源类的隐藏引用点。

3、编译、测试。

4、运用Move Method和Move Field，将源类的特性全部搬移到目标类。

5、为源类举行一个简单的“丧礼”。

五、Hide Delegate(隐藏“委托关系”)

客户通过一个委托类来调用另一个对象。

在服务类上建立客户所需的所有函数，用以隐藏委托关系。

动机

“封装”即使不是对象的最关键特征，也是最关键特征之一。“封装”意味着每个对象都应该尽可能少了解系统的其他部分。如此一来，一旦发生变化，需要了解这一变化的对象就会比较少--这会使变化比较容易进行。

如果某个客户先通过服务对象的字段得到两一个对象，然后调用后者的函数，那么客户就必须知晓这一层委托关系。万一委托关系发生变化，客户也得相应变化。你可以在服务对象上放置一个简单的委托函数，将委托关系隐藏起来，从而去除这种依赖。这么一来，即便发生委托关系上的变化，变化也将限制在服务对象中，不会波及客户。

做法

1、对于每一个委托关系中的函数，在服务对象端建立一个简单的委托函数。

2、调整客户，令它只调用服务对象提供的函数。

? 如果使用者和服务提供者不在同一个包，考虑修改委托函数的访问权限，让客户得以在包外调用它。

3、每次调整后，编译、测试。

4、如果将来不再有客户需要取用的Delegate(受托类)，便可移除访问对象中的相关访问函数。

5、编译、测试。