重构第三章：何时重构——22种坏味道

1、重复代码

2、方法过长

3、类过大

4、过长参数列

5、发散式变化，类由于不同的原因在不同的地方发生变化。怎么解决：运用Extract Class部分内容提炼到一个新类中，这样每个类都因只因一种变化而需要修改。策略模式是对付发散式变化的典型手段。

6、散弹式修改，也就是说当系统需要修改时，只用修改某一处，而不用修改多个地方。怎么解决：使用Move Method 和 Move Field把所有需要修改的代码放进同一个类，如果没有则创建一个这样的类。

5和6的区别和联系：发散式变化指：一个类受多种变化的影响，散弹式修改指：一种变化引起多个类（多个地方）修改。解决办法的目的相同：使外界变化与需泥巴修改的类趋于一一对应。

7、Feature Envy（特性依恋）：多某个类的数据过分依赖。判断原则：某个类的函数使用最多的应的本类的数据，而不是其他的类，否则就是Feature Envy。解决办法：Extract method将使用其他类的数据的代码抽取，然后Move Method移动至合理的类中。

8、数据泥团：类中有关联的字段、不同方法的签名中相同的参数。解决办法：运用Extract Class将数据提炼到一个独立的对象中，然后使用对象代替这些独立的字段。

9、基本类型偏执。解决办法：可以使用小对象将基本数据进行封装，而不过度依赖基本数据。

10、switch代码块。面向对象程序的最明显特征就是：少用stitch case代码语句。解决办法：大多数时候，一看到switch语句，就应该考虑以多态来替换它，switch一般是根据type来判断，因此有两种方式：一种是用子类来替代Type判断，另一种是使用策略模式替代Type判断，本质上都是通过多态来判断。

11、平行继承体系：每当需要为一个类增加一个子类，必须也为另一个类相应增加一个子类。解决办法：P83，没有例子，暂未理解。

12、冗余类。对于几乎没有用的类，应该消失。

13、Speculative Generality（推测一般性）：即没有用到的类、方法应除掉。

14、迷惑的临时字段：即有的字段只是某些函数需求或者某些情况下会使用，这些字段不能作为对象的字段。解决办法：可以将这些字段Extract Class抽离出来到一个独立的类中。

15、过度耦合的消息链（对象调用链）：一个对象请求另一个对象，再向后者请求另一个对象...，导致一长串的请求链。解决办法：P84，未理解，需要具体的例子加以理解。

16、过度运用委托（Middle Man）。解决办法：Remove Middle Man, 直接和真正负责的对象打交道。

17、过度亲密的类。解决办法：Move Method和Move Field将类划清界限，或者Extract Class将共同点提炼到一个新的类。继承往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望，可以用委托（代理）代替继承。

18、异曲同工的类：解决办法：Extract SuperClass在父类上做文章。

19、不完成的类库。解决办法：修改类库使它完成我们希望完成的工作，运用Introduce Foreign Method修改库类的一两个函数，运用Introduce Local Extension添加一大推额外行为。

20、Data Class（单纯的数据类）。解决办法：字段进行封装，字段的获取和修改，通过方法对外暴露。

21、拒绝继承：子类复用了超类的行动（实现），却不愿意支持超类的接口。解决办法：不要修改继承体系，而是使用Replace Inheritance with Delegation，需要具体例子来理解。

22、过多的注释：长长的注释的存在，通常是因为代码很糟糕。重构之后，注释已经变成了多余了，因为代码已经清楚说明了一切，因此可以拿掉注释。当你感觉需要写注释时，首先尝试重构，试着让所有注释变得多余。重构步骤：Extract Method和Rename Method来解释代码块的行动，Introduce Assertion来说明系统的需求规格。