《重构》第三章学习笔记
前面两张学习了如何进行重构，那么选择什么情况下进行重构呢？
本章介绍了22种应该需要进行重构的情况。
重复代码
合并相同的程序结构，如果并非完全相同，就要将相同的和差异的部分分隔开。
过长函数
程序越长越难理解，将长函数分割为小函数，并且要取一个能让开发者一眼就能看出其中功能的函数名。
过大的类
根据功能提炼类的接口能够更清楚的分解类。
过长参数列
太多的参数列难以让开发者理解，太多的参数会造成前后不一致，不宜使用。
发散式变化
针对外界所有相应修改，都只应该发生在单一类中，而这个新类内所有内容都应该反映次变化。找出特定原因而造成的所有变化，然后将他们提炼到另一个类中。
霰弹式修改
一种变化引发多个类相应修改，把一系列相关行为放进同一个类，虽然会造成少量的Divergent Change(一个类受多种变化的影响)，但是可以轻易的处理它们。
依恋情节
依恋情节是函数对某个类的兴趣高过对自己类的兴趣，判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据放在一起。
数据泥团
创造新类时寻找有依恋情节的方法。
基本类型偏执
对常常放在一起的基本类型参数进行封装。
Switch惊悚现身
switch造成重复的问题，将其提炼到单独的方法中。
平行继承体系
让一个继承体系的实例引用另一个继承体系的实例。
冗赘类
对于几乎没用的组件应该删除。
夸夸其谈未来性
如果某个抽象类其实没有太大的作用，当前不值得维护，将其删除。
令人迷惑的暂时字段
对于使用某个算法时使用的临时变量，将其都放在字段中。
过度耦合的消息链
大量参数的传递会造成过度耦合，可以将其封装进对象中。
中间人
作用不大的中间函数可以删除
狎昵关系
如果子类的功能超出了父类的范围，应将其单独出来。
异曲同工的类
虽然操作不同的对象但做同一件事的，可以将其稍作修改使其合并。
不完美的类库
如果类库不够好，可以尝试修改类库中的函数。
纯稚的数据类
在数据类中使用Getter，Setter。
被拒绝的遗赠
子类复用父类的实现时，一定要继承父类的接口。
过多的注释
重构结束后删除多余的注释。