重构-改善既有代码的设计
重构的基本定义：重构是在不改变软件可观察行为的前提下，改善其内部结构。
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构步骤
1. 测试
重构之前，首先检查自己是否有一套可靠的测试机制，这些测试必须有自我检验能力。
重构原则
何时重构
如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，
那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。
- 添加功能时重构
- 修补错误时重构
- 审复代码时重构
程序的坏味道
Duplicated Code（重复代码）
Long Method（过长函数）
Large Class（过大的类）
Long Parameter List（过长参数列）
Divergent Change（发散式变化： 一个类受多种变化的影响）
如果某个类经常因为不同的原因在不同的方向上发生变化，Divergent Change就出现了。
Shotgun Surgery（霰弹式修改：一种变化引发多个类相应修改）
如果每遇到某种变化，都必须在许多不同的类内做出许多小修改，这就是Shotgun Surgery。
Feature Envy（依恋情结）
某函数过多的调用、依赖于另一对象的函数。
Data Clumps（数据泥团）
常常在很多地方出现相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。
这些总是绑在一起出现的数据应该拥有属于它们自己的对象。
Primitive Obsession（基本类型偏执）
不愿意在小任务上运用小对象——像是结合数值和币种的money类、由一个起始值和一个结束值组成的range类、电话号码或邮政编码（ZIP）等等。
Switch Statements（
switch惊悚现身）大多数时候，一看到
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（幼稚的数据类）
Refused Bequest（被拒绝的遗赠）
Comments（过多的注释）
| 烂程序 | 我们希望的程序 |
|---|---|
| 难以阅读的程序，难以修改 | 容易阅读 |
| 逻辑重复的程序，难以修改 | 所有逻辑都只在唯一地点指定 |
| 添加新行为时需要修改已有代码的程序，难以修改 | 新的改动不会危及现有行为 |
| 带复杂条件逻辑的程序，难以修改 | 尽可能简单表达条件逻辑 |
构筑测试体系
确保所有测试都完全自动化，让它们检查自己的测试结果。
一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。
编写未完善的测试并实际运行，好过对完美测试的无尽等待。
考虑可能出错的边界条件，把测试火力集中在那儿。
当事件被认为应该会出错时，别忘了检查是否抛出了预期的异常。
不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。
重构列表
重构的基本技巧——小步前进、频繁测试
重构的记录格式
名称（name）
概要（summary）
动机（motivation）
做法（mechanics）
范例（example）
重新组织函数
1. Extract Method（提炼函数）
你有一段代码可以被组织在一起并独立出来。
使用率：★★★★★
2. Inline Method（内联函数）
一个函数的本体与名称同样清楚易懂。
使用率：★★☆☆☆
3. Inline Temp（内联临时变量）
你有一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法。
使用率：★★☆☆☆
4. Replace Temp with Query（以查询取代临时变量）
你的程序以一个临时变量保存某一表达式的运算结果。
使用率：★★☆☆☆
5. Introduce Explaining Variable（引入解释性变量）
你有一个复制的表达式。
使用率：★★★★☆
6. Split Temporary Variable（分解临时变量）
你的程序有某个临时变量被赋值超过一次，它既不是循环变量，也不被用于收集计算结果。
使用率：★★★☆☆
7. Remove Assignments to Parameters（移除对参数的赋值）
代码对一个参数进行赋值。
使用率：★★☆☆☆
8. Replace Method with Method Object（以函数对象取代函数）
你有一个大型函数，其中对局部变量的使用使你无法采用Extract Method（提炼函数）。
使用率：★★☆☆☆
9. Substitute Algorithm（替换算法）
你想要把某个算法替换为另一个更清晰的算法。
使用率：★★☆☆☆
在对象之间搬移特性
1. Move Method（搬移函数）
你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。
使用率：★★★★☆
2. Move Field（搬移字段）
你的程序中，某个字段被其所驻类之外的另一个类更多地用到。
使用率：★★★★☆
3. Extract Class（提炼类）
某个类做了应该由两个类做的事。
使用率：★★★★☆
4. Inline Class（将类内联化）
某个类没有做太多事情。
使用率：★★★☆☆
5. Hide Delegate（隐藏“委托关系”）
客户通过一个委托类来调用另一个对象。
使用率：★★★☆☆
6. Remove Middle Man（移除中间人）
某个类做了过多的简单委托动作。
使用率：★★★☆☆
7. Introduce Foreign Method（引入外加函数）
你需要为提供服务的类增加一个函数，但你无法修改这个类。
使用率：★★★☆☆
8. Introduce Local Extension（引入本地扩展）
你需要为服务类提供一些额外函数，但你无法修改这个类。
使用率：★★★☆☆
重新组织数据
1. Self Encapsulate Field（自封装字段）
你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。
使用率：★★★★☆
2. Replace Data Value with Object（以对象取代数据值）
你有一个数据项，需要与其他数据和行为一起使用才有意义。
使用率：★★★★☆
3. Change Value to Reference（将值对象改为引用对象）
你从一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象。
使用率：★★★★☆
4. Change Reference to Value（将引用对象改为值对象）
你有一个引用对象，很小且不可变，而且不易管理。
使用率：★★☆☆☆
5. Replace Array with Object（以对象取代数组）
你有一个数组，其中的元素各自代表不同的东西。
使用率：★☆☆☆☆
6. Duplicate Observed Data（复制“被监视数据”）
你有一些领域数据置身于GUI控件中，而领域函数需要访问这些数据。
使用率：★★★☆☆
7. Change Unidirectional Association to Bidirectional（将单向关联改为双向关联）
两个类都需要使用对方特性，但其间只有一条单向连接。
使用率：★★☆☆☆
8. Change Bidirectional Association to Unidirectional（将双向关联改为单向关联）
两个类之间有双向关联，但其中一个类如今不再需要另一个类的特效。
使用率：★☆☆☆☆
9. Replace Magic Number with Symbolic Constant（以字面常量取代魔法数）
你有一个字面数值，带有特别含义。
使用率：★★★☆☆
10. Encapsulate Field（封装字段）
你的类中存在一个public字段。
使用率：★★★☆☆
11. Encapsulate Collection（封装集合）
有个函数返回一个集合。
使用率：★★★☆☆
12. Replace Record with Data Class（以数据类取代记录）
你需要面对传统编程环境中的记录结构。
使用率：★☆☆☆☆
13. Replace Type Code with Class（以类取代类型码）
类之中有一个数值类型码，但它并不影响类的行为。
使用率：★★★☆☆
14. Replace Type Code with Subclasses（以子类取代类型码）
你有一个不可变的类型码，它会影响类的行为。
使用率：★★☆☆☆
15. Replace Type Code with State/Strategy（以State/Strategy取代类型码）
你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它。
使用率：★★☆☆☆
16. Replace Subclass with Fields（以字段取代子类）
你的各个子类的唯一差别只在“返回常量数据”的函数身上。
使用率：★★☆☆☆
简化条件表达式
1. Decompose Conditional（分解条件表达式）
你有一个复杂的条件（if-then-else）语句。
使用率：★★★★☆
2. Consolidate Conditional Expression（合并条件表达式）
你有一系列条件测试，都得到相同结果。
使用率：★★★☆☆
3. Consolidate Duplicate Conditional Fragments（合并重复的条件片段）
在条件表达式的每个分支上有着相同的一段代码。
使用率：★★☆☆☆
4. Remove Control Flag（移除控制标记）
在一系列布尔表达式 中，某个变量带有“控制标记”（control flag）的作用。
使用率：★☆☆☆☆
5. Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件表达式）
函数中的条件逻辑使人难以看清正常的执行路径。
使用率：★★★☆☆
6. Replace Conditional with Polymorphism（以多态取代条件表达式）
你手上有个条件表达式，它根据对象类型的不同而选择不同的行为。
使用率：★★☆☆☆
7. Introduce Null Object（引入Null对象）
你需要再三检查对象是否为null。
使用率：★★☆☆☆
8. Introduce Assertion（引入断言）
某一段代码需要对程序状态做出某种假设。
使用率：★★☆☆☆
简化函数调用
1. Rename Method（函数改名）
函数的名称未能揭示函数的用途。
修改函数名称。
给函数命名有一个好办法：首先考虑应该给这个函数写上一句怎样的注释，然后想办法将注释变成函数名称。
使用率：★★★★★
2. Add Parameter（添加参数）
某个函数需要从调用端得到更多信息。
为此函数添加一个对象参数，让该对象带进函数所需信息。
使用率：★★★☆☆
3. Remove Parameter（移除参数）
函数本体不再需要某个参数。
将该参数去除。
使用率：★★★☆☆
4. Separate Query from Modifier（将查询函数和修改函数分离）
某个函数既返回对象状态值，又修改对象状态。
建立两个不同的函数，其中一个负责查询，另一个负责修改。
明确“有副作用”与“无副作用”两种函数之间的差异：如何有返回值的函数，都不应该有看得到的副作用。
使用率：★★★★★
5. Parameterize Method（令函数携带参数）
若干函数做了类似的工作，但在函数本体中却包含了不同的值。
建立单一函数，以参数表达那些不同的值。
使用率：★★★★☆
6. Replace Parameter with Explicit Methods（以明确函数取代参数）
你有一个函数，其中完全取决于参数值而采取不同行为。
针对该参数的每一个可能值，建立一个独立函数。
使用率：★★★★☆
7. Preserve Whole Object（保持对象完整）
你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。
改为传递整个对象。
使用率：★★★★☆
8. Replace Parameter with Methods（以函数取代参数）
对象调用某个函数，并将所得结果作为参数，传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数。
让参数接受者去除该项参数，并直接调用前一个函数。
使用率：★★★☆☆
9. Introduce Parameter Object（引入参数对象）
某些参数总是很自然地同时出现。
以一个对象取代这些参数。
使用率：★★★☆☆
10. Remove Setting Method（移除设值函数）
类中的某个字段应该在对象创建时被设值，然后就不再改变。
去掉该字段的所有设值函数。
使用率：★★☆☆☆
11. Hide Method（隐藏函数）
有一个函数，从来没有被其他任何类用到。
将这个函数修改为private
使用率：★★☆☆☆
12. Replace Constructor with Factory Method（以工厂函数取代构造函数）
你希望在创建对象时不仅仅是做简单的构建动作。
将构造函数替换为工厂函数。
使用率：★★★☆☆
13. Encapsulate Downcast（封装向下转型）
某个函数返回的对象，需要由函数调用者执行向下转型（downcast）。
将向下转型动作移到函数中。
使用率：★★☆☆☆
14. Replace Error Code with Exception（以异常取代错误码）
某个函数返回一个特定的代码，用以表示某种错误情况。
改为异常。
使用率：★★★★☆
15. Replace Exception with Test（以测试取代异常）
面对一个调用者可以预先检查的条件，你抛出了一个异常。
修改调用者，使它在调用函数之前先做检查。
使用率：★★★☆☆
处理概括关系
1. Pull Up Field（字段上移）
两个子类拥有相同的字段。
将该字段移至超类。
使用率：★★★★★
2. Pull Up Method（函数上移）
有些函数，在各个子类中产生完全相同的结果。
将该函数移至超类。
使用率：★★★★★
3. Pull Up Constructor Body（构造函数本体上移）
你在各个子类中拥有一些构造函数，它们的本体几乎完全一致。
在超类中新建一个构造函数，并在子类构造函数中调用它。
使用率：★★★★☆
4. Push Down Method（函数下移）
超类中的某个函数只与部分（而非全部）子类有关。
将这个函数移到相关的那些子类去。
使用率：★★★★☆
5. Push Down Field（字段下移）
超类中的某个字段只被部分（而非全部）子类用到。
将这个字段移到需要它的那些子类去。
使用率：★★★★☆
6. Extract Subclass（提炼子类）
类中的某些特性只被某些（而非全部）实例用到。
新建一个子类，将上面所说的那一部分特性移到子类中。
使用率：★★★★☆
7. Extract Superclass（提炼超类）
两个类有相似特性。
为这两个类建立一个超类，将相同特性移至超类。
使用率：★★★★☆
8. Extract Interface（提炼接口）
若干客户使用类接口中的同一子集，或者两个类的接口有部分相同。
将相同的子集提炼到一个独立接口中。
使用率：★★★★★
9. Collapse Hierarchy（折叠继承体系）
超类和子类之间无太大区别。
将它们合为一体。
使用率：★★☆☆☆
10. Form Template Method（塑造模版函数）
你有一些子类，其中相应的某些函数以相同顺序执行类似的操作，但各个操作的细节上有所不同。
将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。
使用率：★★★★★
11. Replace Inheritance with Delegation（以委托取代继承）
某个子类只使用超类接口中的一部分，或是根据不需要继承而来的数据。
在子类中新建一个字段用以保存超类；调整子类函数，令它改而委托超类；然后去掉两者之间的继承关系。
使用率：★★★★☆
12. Replace Delegation with Inheritance（以继承取代委托）
你在两个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。
让委托类继承受托类。
使用率：★★★☆☆
大型重构
1. Tease Apart Inheritance（梳理并分解继承体系）
某个继承体系同时承担两项责任。
建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
使用率：★★★★★
2. Convert Procedural Design to Objects（将过程化设计转化为对象设计）
你手上有一些传统过程化风格的代码。
将数据记录变成对象，将大块的行为分成小块，并将行为移入相关对象之中。
使用率：★★★★☆
3. Separate Domain from Presentation（将领域和表述/显示分离）
某些GUI类之中包含了领域逻辑。
将领域逻辑分离出来，为它们建立独立的领域类。
使用率：★★★★☆
4. Extract Hierarchy（提炼继承体系）
你有某个类做了太多工作，其中一部分工作是以大量条件表达式完成的。
建立继承体系，以一个子类表示一种特殊情况。
使用率：★★★☆☆