什么是重构
所谓重构是这样一个过程：在不改变代码外在行为的前提下，对代码作出修改，以改进程序的内部结构。本质上说，重构就是在代码写好之后改进它的设计。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构的目的是使软件更容易被理解和修改。重构不会改变软件可观察的行为——重构之后软件功能一如既往。而重构技术就是以微小的步伐修改程序，如果你犯下错误，很容易便可以发现它。
为何重构
1、重构改进软件设计
只为了短期目的或者在完全理解整体设计之前编写出来的代码，会导致程序逐渐失去自己的结构。这时如果没有重构，程序的设计会逐渐腐败变质，程序员愈来愈难通过阅读源码而理解原本设计。重构很像是在整理代码，你所做的就是让所有东西回到应该的位置上。代码结构的流失是累积性的。愈难看出代码所代表的设计意涵，就愈难保护其中设计，于是该设计就腐败得愈快。经常性的重构可以帮助代码维持自己该有的形态。
2、重构使软件更容易理解
所谓程序设计，很大程度上就是与计算机交谈：你编写代码告诉计算机做什么事，它的响应则是精确按照你的指示行动。你得及时填补“想要它做什么”和“告诉它做什么”之间的缝隙。这种编程模式的核心就是“准确说出我所要的”。除了计算机外，你的源码还有其他读者：几个月之后可能会有另一位程序员尝试读懂你的代码并做一些修改。我们很容易忘记这第二位读者，但他才是最重要的。计算机是否多花了几个小时来编译，又有什么关系呢?如果一个程序员花费一周时间来修改某段代码，那才关系重大—如果他理解你的代码，这个修改原本只需一小时。
3、重构帮助找到bug
对代码的理解，可以帮助我们找到bug。有些人只要盯着一大段代码就可以找出里面的bug，但大多数人不行。如果对代码进行重构，我们就可以深入理解代码的作为，并恰到好处地把新的理解反馈回去。搞清楚程序结构的同时，也清楚了自己所做的一些假设，从而更加容易把bug揪出来。
4、重构提高编程速度
良好的设计是快速开发的根本──事实上，拥有良好设计才可能做到快速开发。如果没有良好设计，或许某一段时间内你的进展迅速，但恶劣的设计很快就让你的速度慢下来。你会把时间花在调试上面，难以或者甚至无法添加新功能，修改时间愈来愈长，扩展性与可维护性越来越差。因为你必须花愈来愈多的时间去理解系统、寻找重复代码。随着你给最初程序打上一个又一个的补丁，新特性需要更多代码才能实现，最终变成一个恶性循环。
5、重构使单元测试成为可能
Android作为对单元测试最不友好的系统环境，大多数开发者在刚开始接触时都会直观地把和当前界面有关的所有逻辑都放在Activity或者Fragment等视图里面，造成View层与逻辑层甚至数据层深度耦合，而单元测试对View的测试非常乏力，也不值得花大量时间在这上面，同时因为逻辑的过度耦合，每一个类里面有非常多的私有依赖无法进行mock，从而无法达到尽可能全面测试的目的。但是单元测试可以测出整个测试流程中80%的bug，这是对代码质量的一个重大保障。
6、重构应该是开发人员的必备技术手段
一名开发人员的良好发展路线应该是由会写代码转为写好代码，也是从一名实现者到架构者的转变，甚至即使是单纯的实现者，也应该追求自己能写出越来越优雅和高效的代码。业务需求与技术需求不应该是对立面，技术需求最终也是服务于业务需求，更好的代码结构才能帮助项目更快速地开发。
何时重构
重构不是一件应该特别拨出时间做的事情，重构应该随时随地进行。不应该为重构而重构，之所以重构，是因为我们想做别的什么事，而重构可以帮助我们把那些事做好。
添加功能时重构。
修补错误时重构。
复审代码时重构。
三次法则：事不过三，三则重构。
何时不该重构
代码根本无法工作或者太糟糕，重构还不如重写来的简单。
在项目的最后期限，应该避免重构。
代码的坏味道
重复代码(Duplicated Code)
同一个类的两个函数还有相同的表达式，这时需要提炼出重复代码。
两个互为兄弟的子类内含有相同的表达式，可以提炼相同代码，并放到父类中。如果只是代码间相似，并非完全相同，那么可以将相似部分和差异部分拆开，构成单独的函数。然后你可以使用模板方法的设计模式。
如果两个毫不相关的类中出现重复代码，则可以将重复代码提炼成一个函数放到一个独立类中或者只放在某一个类中（总之要放在合适的地方），然后其他类都去调用这个函数。
过长函数(Long Method)
原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫的那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。
过大的类(Large Class)
类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。如果有五个“百行函数”，它们之间很多代码都相同，那么或许你可以把它们编程五个“十行函数”和十个提炼出来的“双行函数”。
过长参数列(Long Parameter List)
有了对象，就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。函数需要的东西多半可以在函数宿主类中找到。如果将对象传递给函数，大多数修改都将没有必要，因为你很可能只需（在函数内）增加一两条请求，就能得到更多的数据。
这里有一个重要的例外：有时候你明显不希望造成“被调用对象”与“较大对象”间的某种依赖关系。这时候将数据从对象中拆解出来单独作为参数，也很合情合理。
发散式变化(Divergent Change)
一个类受多种变化的影响
如果某个类经常因为不同的原因在不同的方向上发生变化，发散式变化的坏味道就出现了。针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应次变化。
霰弹式修改(Shotgun Surgery)
一种变化引发多个类相应修改
如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霰弹式修改。这种情况下，可以把所有需要修改的代码放进同一个类，如果没有合适的类可放，就创造一个。
依恋情结(Feature Envy)
函数对某个类的兴趣高过自己所处类的兴趣
对象技术的全部要点在于：这是一种“将数据和对数据的操作行为包装在一起”的技术。
有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。
处理这种坏味道的原则是：判断哪个类拥有最多被此函数实用的数据，然后就把这个函数和那些数据摆在一起。
最根本的原则是：将总是一起变化的东西放在一块。
数据泥团(Data Clumps)
相同的若干项数据出现在不同地方，这些绑在一起出现的数据应该有属于它们自己的对象
一个好的评判办法是：删掉众多数据中的一项，其他数据有没有因此而失去意义？如果他们不再有意义，这就是一个明确信号：你应该为它们产生一个新对象。
基本类型偏执(Private Obsession)
很多人不愿意在小任务上运用小对象
对象技术的新手通常不愿意在小任务上运用小对象。
如果你有一组应该总是被放在一起的字段（基本类型的数据），那么可以尝试将这组数据放到一个单独类中变成结构类型的数据
switch惊悚现身(Switch Statements)
switch语句会在很多地方重复出现，一改则需全改
面向对象程序的一个最明显特征就是：少用switch（或case）语句。从本质上说，switch语句的问题在于重复。面向对象中的多态概念可为此带来优雅的解决办法。
平行继承体系(Parallel Inheritance Hierarchies)
当你为某一个类增加子类时，也必须为另一个类相应增加一个类
如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，便是问到了这种坏味道。
消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
冗赘类(Lazy Class)
如果一个类不值得存在，那就让它消失
夸夸其谈的未来星(Speculative Generality)
预留的无用的抽象类，无用的抽象参数
当有人说“噢， 我想我们总有一天需要做这件事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。
令人迷惑的暂时字段(Temporary Field)
类中某个字段只为某些特殊情况而设置
过度耦合的消息链(Message Chains)
用户向一个对象请求另一个对象，然后再向后者请求另一个对象……
中间人(Middle Man)
无用的委托，过多的中间层
狎昵关系(Inappropriate Intimacy)
两个类过于亲密，一个类过于关注另一个类的成员
异曲同工的类(Alternative Classes with Different Interfaces)
不同名字的类或函数，作者相同的事
不完美的库类(Incomplete Library Class)
类库设计不可能完美
纯数据类(Data Class)：一个类拥有一些字段以及用于访问这些字段的函数，除此之外一无长物
纯稚的数据类是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
这种类如果get/set方法均是public的，则需要引起注意，应该进行适当的封装，而不是全部公有化。
被拒绝的遗赠(Refused Bequest)：子类不想继承超类所有的函数和数据，只想挑几样来玩
子类应该继承超类的函数和数据。但如果他们不想或不需要继承所有的函数和数据，则应该为这个子类新建一个兄弟类，把所有用不到的函数和数据放到兄弟类中，他们共享的数据和函数则放到共同的超类中。
过多的注释(Comments)
当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余
如果你不知道该做什么的，这才是注释的良好运用时机。
构筑测试体系
重构的首要前提是拥有一个可靠的测试环境。
只要写好一点功能，就立即添加测试，并确保所有测试都完全自动化，让它们检查自己的测试结果。一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。
撰写测试代码的最有用时机是在开始编程之前。当你需要添加特性的时候，先写相应测试代码。编写测试代码其实就是在问自己：添加这个功能需要做些什么。编写测试代码还能使你把注意力集中于接口而非实现。预先写好的测试代码也为你的工作安上一个明确的结束标志：一旦测试代码正常运行，工作就可以结束了。
多运用单元测试。测试你最担心出错的地方，考虑可能出错的边界条件。不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。“花合理时间抓出大多数bug”要好过“穷尽一生抓出所有bug”。
重构手法
1、重新组织函数
提炼函数（Extract Method）
你有一段代码可以被组织在一起并独立出来。将这段代码放进一个独立函数中，并将函数名称解释该函数的用途。
动机：首先，如果每个函数的粒度都很小，那么函数被服用的机会就更大；其次，这回是高层函数读起来就像一系列注释；再次，如果函数都是细粒度，那么函数的覆写也会更容易些。函数的长度不是问题，关键在于函数名称和函数本体之间的语义距离。如果提炼可以强化代码的清晰度，那么就去做，就算函数名称比提炼出来的代码还长也无所谓。
做法：创造一个新函数，根据这个函数的意图来对它命名（以它“做什么”来命名，而不是以它“怎样做”命名）。
内联函数（Inline Method）
一个函数的本体与名称同样清楚易懂。在函数调用点插入函数本体，然后移除该函数。
内联临时变量（Inline Temp）
你有一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法。将所有对该变量的引用动作，替换为对它赋值的那个表达式自身。
以查询取代临时变量（Replace Temp with Query）
你的程序以一个临时变量保存某一表达式的运算结果。将这个表达式提炼到一个独立函数中。将这个临时变量的所有引用点替换为对新函数的调用。此后，新函数就可被其他函数使用。
引入解释性变量（Introduce Explaining Variable）
你有一个复杂的表达式。将该复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
分解临时变量（Split Temporary Variable）
你的程序有某个临时变量被赋值过一次，它既不是循环变量，也不被用于收集计算结果。针对每次赋值，创造一个独立、对应的临时变量。
移除对参数的赋值（Remove Assignments Parameters）
代码对一个参数进行赋值。以一个临时变量取代参数的位置。
以函数对象取代函数（Replace Method with Method Object）
你有一个大型函数，其中对局部变量的使用使你无法采用Extract Method。将这个函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。
替换算法（Substitute Algorithm）
你想要把某个算法替换为另一个更清晰的算法。将函数本体替换为另一个算法。
2、在对象之间搬移特性
搬移函数（Move Method）
你的程序中，有个函数与其所驻之外的另一个类进行更多交流：调用后者，或被后者调用。在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是将旧函数完全移除。
搬移字段（Move Field）
你的程序中，某个字段被其所驻类之外的另一个类更多地用到。在目标类新建一个字段，修改源字段的所有用户，令它们改用新字段。
提炼类（Extract Class）
某个类做了应该有两个类做的事。建立一个新类，将相关的字段和函数从旧类搬移到新类。
将类内联化（Inline Class）
某个类没有做太多事情。将这个类的所有特性搬移到另一个类中，然后移除原类。
隐藏“委托关系”（Hide Delegate）
客户通过一个委托来调用另一个对象。在服务类上建立客户所需的所有函数，用以隐藏委托关系。
移除中间人（Remove Middle Man）
某个类做了过多的简单委托动作。让客户直接调用受托类。
引入外加函数（Introduce Foreign Method）
你需要为提供服务的类增加一个函数，但你无法修改这个类。在客户类中建立一个函数，并以第一参数形式传入一个服务类实例。
引入本地扩展（Introduce Local Extension）
你需要为服务类提供一些额外函数，但你无法修改这个类。建立一个新类，使它包含这些额外函数。让这个扩展品成为源类的子类或包装类。
3、重新组织数据
自封装字段（Self Encapsulate Field）
你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。为这个字段建立取值/设值函数，并且只以这些函数来访问字段。
以对象取代数据值（Replace Data Value with Object）
你有一个数据项，需要与其他数据和行为一起使用才有意义。将数据项变成对象。
将值对象改为引用对象（Change Value to Reference）
你从一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象。将这个值对象变成引用对象。
将引用对象改为值对象（Change Reference to Value）
你有一个引用对象，很小且不可变，而且不易管理。将它变成一个值对象。
值对象有一个非常重要的特性：它们应该是不可变的。
定义了equals()，就必须同时定义hashCode()。实现hashCode()有个简单的办法：读取equals()使用的所有字段的hash码，然后对它们进行按位异或（^）操作。
以对象取代数据（Replace Array with Object）
你有一个数组，其中的元素各自代表不同的东西。以对象替换数组，对于数组中的每个元素，以一个字段来表示。
用对象替代数组的好处就是就对数组的各种操作都可以封装起来。因此，对于那些需要各种操作的数组，最好封装起来。
复制“被监视数据”（Duplicate Observed Data）
你有一些领域数据置身GUI控件中，而领域函数需要访问这些数据。将该数据复制到一个领域对象中。建立一个Observe模式，用以同步领域对象和GUI对象内的重复数据。
将单向关联改为双向关联（Change Unidirectional Association to Bidirectional）
两个类都需要使用对方特性，但其间只有一条单向链接。添加一个反向指针，并使修改函数能够同时更新两条链接。
将双向关联改为单向关联（Change Bidirectional Association to Unidirectional）
两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。去除不必要的关联。
以字面常量取代魔法数（Replace Magic Number with Symbolic Constant）
你有一个字面数值，带有特别含义。创造一个常量，根据其意义为它命名，并将上述的字面数值替换为这个常量。
封装字段（Encapsulate Field）
你的类中存在一个public字段。将它声明为private，并提供相应的访问函数。
封装集合（Encapsulate Collection）
有个函数返回一个集合。让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数。
以数据类取代记录（Replace Record with Data Class）
你需要面对传统编程环境中的记录结构。为该记录创建一个“哑”数据对象。
以类取代类型码（Replace Type Code with Class）
类之中有一个数值类行码，但它并不影响类的行为。以一个新的类替换该数值类型码。
以子类取代类型码（Replace Type Code with Subclass）
你又一个不可变的类型码，它会影响类的行为。以子类取代这个类型码。
以State/Strategy取代类型码（Replace Type Code with State/Strategy）
你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它。以状态对象取代类型码。
以字段取代子类（Replace Subclass with Fields）
你的各个子类的唯一差别只在“返回常量数据”的函数身上。修改这些函数，使他么返回超类中的某个（新增）字段，然后销毁子类。
4、简化条件表达式
分解条件表达式（Decompose Conditional）
你有一个复杂的条件（if-then-else）语句。从if、then、else三分段落中分别提炼出独立函数。
合并条件表达式（Consolidate Conditional Expression）
你有一系列条件测试，都得到相同结果。将这些测试合并为一个条件表达式，并将这个条件表达式提炼成为一个独立函数。
如果检查条件各不相同，最终行为却一致，就应该使用“逻辑或”和“逻辑与”将他们合并为一个条件表达式。
如果你认为这些检查的确彼此独立，的确不应该被视为同一次检查，那么就不要使用本项重构。
合并重复的条件片段（Consolidate Duplicate Conditional Fragments）
在条件表达式的每个分支上有着相同的一段代码。将这段重复的代码搬移到条件表达式之外。
移除控制标记（Remove Control Flag）。在一系列布尔表达式中，某个变量带有“控制标记”的作用。以break语句或return语句取代控制标记。
以卫语句取代嵌套条件表达式（Replace nested Conditional with Guard Clauses）
函数中的条件逻辑使人难以看清正常的执行路径。使用卫语句表现所有的特殊情况。
卫语句，是指在方法最终返回语句前，加入其它返回语句（return语句）
拆分条件，然后加入适当的卫语句，以减少条件的嵌套层数
将条件反转，然后加入适当的卫语句，以减少条件的嵌套层数
以多态取代条件表达式（Replace Conditional with Polymorphism）
你手上有个条件表达式，它根据对象类型的不同选择不同的行为。将这个条件表达式的每个分支放进一个子类内的覆写函数中，然后将原始函数声明为抽象函数。
引入Null对象（Introduce Null Object）
你需要再三检查某对象是否为null。将null值替换为null对象。
引入断言（Introduce Assertion）
某一段代码需要对程序状态做出某种假设。以断言明确表现这种假设。
5、简化函数调用
函数改名（Rename Method）
函数的名称未能揭示函数的用途。修改函数的名称。
添加参数（Add Parameter）
某个函数需要从调用端得到更多信息。为此函数添加一个对象参数，让该对象带进函数所需信息。
移除参数（Remove Parameter）
函数本体不再需要某个参数。将该参数去除。
将查询函数和修改函数分离（Separate Query from Modifier）
某个函数既返回对象状态值，又修改对象状态。建立两个不同的函数，其中一个负责查询，另一个负责修改。
令函数携带参数（Parameterize Method）
若干函数做了类似的工作，但在函数本体中却包含了不同的值。建立单一函数，以参数表达那些不同的值。
以明确函数取代参数（Replace Parameter with Explicit Methods）
你有一个函数，其中完全取决于参数值而采取不同行为。针对该参数的每一个可能值，建立一个独立函数。
保持对象完整（Preserve Whole Object）
你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。改为传递整个对象。
有时候，你会将来自同一对象的若干项数据作为参数，传递给某个函数。这样做的问题在于：万一将来被调用的函数需要新的数据项，你就必须查找并修改对此函数的所有调用。如果你把这些数据所属的整个对象传给函数，可以避免这种尴尬的处境，因为被调用函数可以向那个参数对象请求任何它想要的信息。
如果被调用函数使用了来自另一个对象的很多项数据，这可能意味该函数实际上应该被定义在那些数据所属的对象中。
以函数取代参数（Replace Parameter with Methods）
对象调用某个函数，并将所得结果作为参数，传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。让参数接受者去除该项参数，并直接调用前一个函数。
如果函数可以通过其他途径获得参数值，那么它就不应该通过参数取得该值。
过长的参数列会增加程序阅读者的理解难度，因此我们应该尽可能缩短参数列的长度。
引入参数对象（Introduce Parameter Object）
某些参数总是很自然地同时出现。以一个对象取代这些参数。
移除设值函数（Remove Setting Method）
类中的某个字段应该在对象创建时被设值，然后就不再改变。这样的字段应该去掉其对应的设值函数。
如果你为某个字段提供了设值函数，这就暗示这个字段值可以被改变。如果你不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数（同时该字段设为final）。这样你的意图会更加清晰，并且可以排除其值被修改的可能性——这种可能性往往是非常大的。
隐藏函数（Hide Method）
有一个函数，从来没有被其他任何类用到。将这个函数修改为private。
尽可能降低所有函数的可见度。
以工厂函数取代构造函数（Replace Constructor with Factory Method）
你希望在创建对象时不仅仅是做简单的构建动作。将构建函数替换为工厂函数。
在派生子类的过程中以工厂函数取代类型码。
如果要根据类型来创建不同的对象，这些对象有共同的父类，则可以在父类中添加一个工厂函数来创建不同的对象。
封装向下转型（Encapsulate Downcast）
某个函数返回的对象，需要由函数调用者执行向下转型。将向下转型动作移到函数中。
以异常取代错误码（Replace Error Code with Exception）
某个函数返回一个特定的代码，用以表示某种错误情况。改用异常。
以测试取代异常（Replace Exception with Test）
面对一个调用者可以预先检查的条件，你抛出了一个异常。修改调用者，使它在调用函数之前先做检查。
6、处理概括关系
字段上移（Pull Up Field）
两个子类拥有相同的字段。将该字段移至超类。
如果这些字段是private的，你必须将超类的字段声明为protected，这样子类才能引用它。
函数上移（Pull Up Method）
有些函数在各个子类中产生完全相同的结果，则将该函数移至超类。
如果你使用的是一种强类型语言，而待提升函数又调用了一个只出现于子类而未出现于超类的函数，你可以在超类中为被调用函数声明一个抽象函数。
构造函数本体上移（Pull Up Constructor Body）
你在各个子类中拥有一些构造函数，他们的本体几乎完全一致。在超类中新建一个构造函数，并在子类构造函数中调用它。
函数下移（Push Down Method）
超类中的某个函数只与部分（而非全部）子类有关。将这个函数移到相关的那些子类去。
字段下移（Push Down Field）
超类中的某个字段只被部分（而非全部）子类用到。将这个字段移到需要它的那些子类去。
提炼子类（Extract Subclass）
类中的某些特性只被某些（而非全部）实例用到。新建一个子类，将上面所说的那一部分特性移到子类中。
提炼超类（Extract Superclass）
两个类有相似特性。为这两个类建立一个超类，将相同特性移至超类。
提炼接口（Extract Interface）
若干客户使用类接口中的同一子集，或者两个类的接口有部分相同。将相同的子集提炼到一个独立接口中。
折叠继承体系（Collapse Hierarchy）
超类和子类之间无太大差别。将它们合为一体。
塑造模板函数（Form TemPlate Method）
你有一些子类，其中相应的某些函数以相同顺序执行类似的操作，但各个操作的细节上所有不同。将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。
以委托取代继承（Replace Inheritance with Delegation）
某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。在子类中新建一个字段用以保存超类；调整子类函数令它改而委托超类；然后去掉两者之间的继承关系。
以继承取代委托（Replace Delegation with Inheritance）
你在两个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。让委托类来继承受托类。
7、大型重构
梳理并分解继承体系（Tease Apart Inheritance）
如果某个继承体系同时承担两项责任，则可以建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
要指出继承体系是否承担了两项不同的责任并不困难：如果继承体系中的某一特定层级上的所有类，其子类名称都以相同的形容词开始，那么这个体系可能就是承担着两项不同的责任。
将过程化设计转化为对象设计（Convert Procedural Design to Objects）
你手上有一些传统过程化风格的代码。将数据记录变成对象，将大块的行为分成小块，并将行为移入相关对象之中。
将领域和表述/显示分离（Separate Domain from Presentation）
某些GUI类之中包含了领域逻辑。将领域逻辑分离出来，为它们建立独立的领域类。
提炼继承体系（Extract Hierarchy）
你有某各类做了太多工作，其中一部分工作是以大量条件表达式完成的。建立继承体系，以一个子类表示一种特殊情况。
为什么开发者不愿意重构他们的程序
不知道如何重构
如果这些利益是长远的，何必现在付出这些努力呢？长远看来，说不定当项目收获这些利益时，你已经不再职位上了
代码重构是一项额外工作，老板付钱给你，主要是让你编写新功能
重构可能破坏现有程序
看完书本这一章节之后，以及自己进行过项目重构的经验下，其实我们日常开发中很多在做的事情就体现了一些重构手法，比如删除方法参数，分装对象等等，只是我们自己不知道而已。
重构并不难学，真正难的是在于要改变现有代码，对自己的编程思维做出改变，但是这是一种进步性质的改变，如果对技术有所追求，对自己写出的代码有追求，这就是一条必经的路。
而且重构可以带来短期利益，它使软件更易修改，更易维护，长期下来反倒更能节省你的开发时间，而且通过单元测试或者小步重构等方式可以让重构非常安全地进行。
总结
汇总图
要点列表
代码坏味道与重构手法
感想
本书和设计模式一样需要有一定的项目经验，最好是有在写代码过程中发现了一些问题，或者自己进行过一些重构了的情况下看会比较感同身受一些，否则很容易看了就忘或者甚至觉得看不下去。
这本书中的例子都是用Java来写的，例子也大多很简单，所以有经验的话看起来也会快很多，至少相比《设计模式：可复用面向对象软件的基础》要快得多。
近来经常看到很多人鼓吹重构无用，甚至说重构就不应该修改代码，对于这种观点不想评价什么，但是重构作为常年位居程序员必看书目的前列应该就可以说明很多问题，很多技术不是没有用，只是你还没到觉得它有用的境界，或者你不会用。
不管怎么样，重构和设计模式等诸多思想一样，是需要反复学习，反复实践，反复总结的，等你接触并真正吸收了这些优秀的思想之后，相信一定会看到一个不一样的代码世界。
最后发一句书作者说的一句话，深以为然：
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
——Martin Fowler
来源：林炳河
