【重构学习】02 何处重构？

1、重复代码

　　解决方案：

• 重复代码位于同一个类：提炼成新函数进行调用
• 重复代码位于不同的子类：提炼成函数放进父类
• 重复代码位于完全不相干的类：提炼出一个新的类，将重复代码放进新的类中
• 重复代码并非完全相同，存在些微差异性：用模版方法的设计模式解决

2、函数过长和参数列过长

　　修改点：

• 有注释的地方就可能有修改点，因为一个地方既然值得你去写注释，那么就已经存在将其提炼出来的可能性，即使它只有一行代码
• 条件表达式和循环处：将分支逻辑和实现细节分离，都可以函数化。而循环可以放到单独的一个函数里。　

　　解决方案：

• 不存在太多参数和临时变量的情况：提炼成新函数进行调用（有太多临时变量和参数，会导致提炼出来的函数可读性可能并不会得到提升）
• 临时变量多：将临时变量替换成查询方法，再进行提炼
• 参数过多：参考参数列过长的处理办法
• 依然存在很多临时变量和参数：用方法对象替代方法，简单地说搞一个类，临时变量作为这个的字段，然后代码提炼为里面的方法

3、过大的类

　　解决方案：提炼新的独立类或者子类

4、参数列过长

　　解决方案：

• 对象替代法：将多个参数放入一个参数对象中，再进行传递（不仅提高可读性，因为传递的只是引用所以会少开辟栈空间，提高性能）
• 函数替代法：看能否将这些参数用函数替代，简单的说就是将这些参数的计算部分放到一个函数里，返回结果再传值

5、发散式变化（一个类受多种变化影响，貌似就是单一职责原则）目标：外界变化和需要修改的类一一对应

　　修改点：软件一旦发生多种变化，但是都修改同一个类，说明此类职责重复

　　解决方案：找出某种特殊原因造成的所有变化，然后将它们提取到另一个类里面

6、霰弹式修改（一个变化修改多个类）目标：外界变化和需要修改的类一一对应

　　修改点：软件一旦发生变化，造成要修改很多类

　　解决方案：找出某种变化引起的不同类中的众多修改点，将各个类中修改点放到一个类中

7、依恋情节

　　修改点：

　　当一个类的函数为了计算经常调用另一个类的一大堆的函数时就表示出现了依恋情节。

　　1和0的世界里面出现了如此具有文艺气质的词，那么我们就用文艺的手法去理解：你们家的女朋友经常去找别人家的汉子时，你多多少少需要知道坏了。

　　解决方案：

　　如果这段代码完全依恋另一个类，那么将此部分出现依恋情节的代码提炼成函数放到另一个类里面（这告诉我们当一个女人完全不爱你的时候要学会放手？）

　　然而很多时候并非这么简单，它两个类都有依恋呢？（然而很多时候并非这么简单，她两个都爱呢？）

　　那就判断哪个类拥有最多被此函数使用的数据，然后就把此函数和那些数据摆在一起。（判断她爱哪个的优点多一点，就让她去找谁吧？）

　　难怪大家都说程序员都是好男人@_@

　　然而Martin大神多说了一句：

　　如果先提取方法将这段代码分割成不同的数个较小的独立函数上述步骤会简单很多。（请恕我直言，左腿和左手我要了，刀交给你了，你随意？）

　　--太可怕了，我先冷静冷静，明天继续

8、数据泥团

9、基本类型偏执

10、Switch惊悚现身

11、平行继承体系

12、冗赘类

13、夸夸其谈未来性

14、令人迷惑的暂时字段

15、过度耦合的消息链

16、中间人

17、狎昵关系

18、异曲同工的类

19、不完美的库类

20、纯稚的数据类

21、被拒绝的遗赠

22、过多的注释

【重构学习】02 何处重构？

原文：http://www.cnblogs.com/vvjiang/p/5084364.html