第1章 重构，第一个案例

1. 代码块俞小，代码的功能就俞容易管理，代码的处理和移动也就俞轻松。（功能也就越单一）
2. 任何不会被修改的变量都可以被当成参数传入新的函数，至于会被修改的变量需要慎重。如果只有一个变量会被修改，可以把它当做返回值。
3. 绝大多数情况下，函数应该放在它所使用的数据的所属对象内。
4. 最好不要在另一个对象的属性基础上运用switch语句。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。
5. 使用继承来适当组织类关系后，可以用多态取代switch语句。
6. 一部影片可以在生命周期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的类。

第2章 重构原则

1. 三次法则：第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次在做类似的是，你就应该重构。事不过三，三则重构。
2. 在重构中引入间接层的某些价值：
   • 允许逻辑共享
   • 分开解释意图和实现
   • 隔离变化
   • 封装条件逻辑
3. 封装条件逻辑。对象有一种奇妙的机制：多态消息，可以灵活而清晰地表达条件逻辑。将条件逻辑转化为消息形式，往往能降低代码的重复、增加清晰度并提高弹性。

第3章 代码的坏味道

1. 重复代码：设法合二为一
   • 同一个类的两个函数还有相同的表达式，这时需要提炼出重复代码。
   • 两个互为兄弟的子类内含有相同的表达式，可以提炼相同代码，并放到父类中。如果只是代码间相似，并非完全相同，那么可以将相似部分和差异部分拆开，构成单独的函数。然后你可以使用模板方法的设计模式。
   • 如果两个毫不相关的类中出现重复代码，则可以将重复代码提炼成一个函数放到一个独立类中或者只放在某一个类中（总之要放在合适的地方），然后其他类都去调用这个函数。
2. 过长函数
   一条原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。哪怕替换后的函数调用动作比函数自身还长，只要函数名称能够解释其用途，我们也该毫不犹豫的那么做。关键不在于函数的长度，而在于函数“做什么”和“如何做”之间的语义距离。
3. 过大的类
   类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。如果有五个“百行函数”，它们之间很多代码都相同，那么或许你可以把它们编程五个“十行函数”和十个提炼出来的“双行函数”。
4. 过长参数列：用对象做参数来减少参数个数
   • 有了对象，就不必把函数需要的所有东西都以参数传递给它了，只需传给它足够的、让函数能从中获得自己需要的东西就行了。函数需要的东西多半可以在函数宿主类中找到。如果将对象传递给函数，大多数修改都将没有必要，因为你很可能只需（在函数内）增加一两条请求，就能得到更多的数据。
   • 这里有一个重要的例外：有时候你明显不希望造成“被调用对象”与“较大对象”间的某种依赖关系。这时候将数据从对象中拆解出来单独作为参数，也很合情合理。
5. 发散式变化：一个类受多种变化的影响
   如果某个类经常因为不同的原因在不同的方向上发生变化，发散式变化的坏味道就出现了。针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应次变化。
6. 霰弹式修改：一种变化引发多个类相应修改
   如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是霰弹式修改。这种情况下，可以把所有需要修改的代码放进同一个类，如果没有合适的类可放，就创造一个。
7. 依恋情节
   • 对象技术的全部要点在于：这是一种“将数据和对数据的操作行为包装在一起”的技术。
   • 有一种经典的气味是：函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。
   • 处理这种坏味道的原则是：判断哪个类拥有最多被此函数实用的数据，然后就把这个函数和那些数据摆在一起。
   • 最根本的原则是：将总是一起变化的东西放在一块。
8. 数据泥团：总是绑在一起的数据应该拥有属于它们自己的对象
   一个好的评判办法是：删掉众多数据中的一项，其他数据有没有因此而失去意义？如果他们不再有意义，这就是一个明确信号：你应该为它们产生一个新对象。
9. 基本类型偏执：将数据组织成有意义的形式，不偏执于基本类型
   • 对象技术的新手通常不愿意在小任务上运用小对象。
   • 如果你有一组应该总是被放在一起的字段（基本类型的数据），那么可以尝试将这组数据放到一个单独类中变成结构类型的数据
10. switch语句
    面向对象程序的一个最明显特征就是：少用switch（或case）语句。从本质上说，switch语句的问题在于重复。面向对象中的多态概念可为此带来优雅的解决办法。
11. 平行继承体系
    • 如果你发现某个继承体系的类名称前缀和另一个继承体系的类名称前缀完全相同，便是问到了这种坏味道。
    • 消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
12. 冗赘类
13. 夸夸其谈未来性
    当有人说“噢， 我想我们总有一天需要做这件事”，并因而企图以各式各样的钩子和特殊情况来处理一些非必要的事情，这种坏味道就出现了。
14. 令人迷惑的临时字段
15. 过度耦合的消息链
16. 中间人
17. 狎昵关系
18. 异曲同工的类
19. 不完美的类库
20. 纯稚的数据类
    • 纯稚的数据类是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。
    • 这种类如果get/set方法均是public的，则需要引起注意，应该进行适当的封装，而不是全部公有化。
21. 被拒绝的遗赠
    子类应该继承超类的函数和数据。但如果他们不想或不需要继承所有的函数和数据，则应该为这个子类新建一个兄弟类，把所有用不到的函数和数据放到兄弟类中，他们共享的数据和函数则放到共同的超类中。
22. 过多的注释
    • 当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余
    • 如果你不知道该做什么的，这才是注释的良好运用时机。

第4章 构筑测试体系

确保所有测试都完全自动化，让他们检查自己的测试结果。

第5章 重构列表

第6章 重新组织函数

1. 提炼函数
   • 动机：首先，如果每个函数的粒度都很小，那么函数被服用的机会就更大；其次，这回是高层函数读起来就像一系列注释；再次，如果函数都是细粒度，那么函数的覆写也会更容易些。函数的长度不是问题，关键在于函数名称和函数本体之间的语义距离。如果提炼可以强化代码的清晰度，那么就去做，就算函数名称比提炼出来的代码还长也无所谓。
   • 做法：创造一个新函数，根据这个函数的意图来对它命名（以它“做什么”来命名，而不是以它“怎样做”命名）。
2. 内联函数
3. 内联临时变量
4. 引入解释性变量
   将复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
5. 分解临时变量
6. 移除对参数的赋值
7. 以函数对象取代函数
8. 替换算法

第7章 在对象之间搬移特性

1. 在对象的设计过程中，“决定把责任放在哪儿”即使不是最重要的事，也是最重要的事之一。
2. 搬移函数
3. 搬移字段
4. 提炼类
5. 将类内联化
6. 隐藏委托关系
7. 移除中间人
8. 引入外加函数
9. 引入本地扩展

第8章 重新组织数据

1. 自封装字段
2. 以对象取代数据值
3. 将值对象改为引用对象
4. 将引用对象改为值对象
   • 值对象有一个非常重要的特性：它们应该是不可变的。
   • 定义了equals()，就必须同时定义hashCode()。实现hashCode()有个简单的办法：读取equals()使用的所有字段的hash码，然后对它们进行按位异或（^）操作。
5. 以对象取代数组

   小结：用对象替代数组的好处就是就对数组的各种操作都可以封装起来。因此，对于那些需要各种操作的数组，最好封装起来。

6. 复制“被监视数据”
7. 将单向关联改为双向关联
8. 将双向关联改为单向关联
9. 以字面常量取代魔法数
10. 封装字段
11. 封装集合
12. 以数据类取代记录
13. 以类取代类型码
14. 以子类取代类型码
15. 以State/Strategy取代类型码
16. 以字段取代子类

第9章 简化条件表达式

1. 分解条件表达式

   如果条件表达式中的条件太多太长，则可以把条件抽取成一个函数，增加代码可读性。

2. 合并条件表达式
   • 如果检查条件各不相同，最终行为却一致，就应该使用“逻辑或”和“逻辑与”将他们合并为一个条件表达式。
   • 如果你认为这些检查的确彼此独立，的确不应该被视为同一次检查，那么就不要使用本项重构。
3. 合并重复的条件片段
4. 移除控制标记
   适当的运用break语句和continue语句可以取代标志位的使用
5. 以卫语句取代嵌套条件表达式
   • 卫语句，是指在方法最终返回语句前，加入其它返回语句（return语句）
   • 拆分条件，然后加入适当的卫语句，以减少条件的嵌套层数
   • 将条件反转，然后加入适当的卫语句，以减少条件的嵌套层数
6. 以多态取代条件表达式
7. 引入Null对象
8. 引入断言

第10章 简化函数调用

1. 函数改名
2. 添加参数
3. 移除参数
4. 将查询函数和修改函数分离
5. 令函数携带参数
6. 以明确函数取代参数
7. 保持对象完整
   • 有时候，你会将来自同一对象的若干项数据作为参数，传递给某个函数。这样做的问题在于：万一将来被调用的函数需要新的数据项，你就必须查找并修改对此函数的所有调用。如果你把这些数据所属的整个对象传给函数，可以避免这种尴尬的处境，因为被调用函数可以向那个参数对象请求任何它想要的信息。
   • 如果被调用函数使用了来自另一个对象的很多项数据，这可能意味该函数实际上应该被定义在那些数据所属的对象中。
8. 以函数取代参数
   • 如果函数可以通过其他途径获得参数值，那么它就不应该通过参数取得该值。
   • 过长的参数列会增加程序阅读者的理解难度，因此我们应该尽可能缩短参数列的长度。
9. 引入参数对象
   某些参数总是很自然地同时出现，这时，可以用一个对象取代这些参数。
10. 移除设值函数
    • 类中的某个字段应该在对象创建时被设值，然后就不再改变。这样的字段应该去掉其对应的设值函数。
    • 如果你为某个字段提供了设值函数，这就暗示这个字段值可以被改变。如果你不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数（同时该字段设为final）。这样你的意图会更加清晰，并且可以排除其值被修改的可能性——这种可能性往往是非常大的。
11. 隐藏函数
    • 不会被其他任何类用到的函数的访问类型应该为private。
    • 尽可能降低所有函数的可见度。
12. 以工厂函数取代构造函数
    • 在派生子类的过程中以工厂函数取代类型码。
    • 如果要根据类型来创建不同的对象，这些对象有共同的父类，则可以在父类中添加一个工厂函数来创建不同的对象。
13. 封装向下转型
    如果某个函数返回的对象，需要由函数调用者执行向下转型，则可以将向下转型动作移到函数中。
14. 以异常取代错误码
15. 以测试取代异常

第11章 处理概括关系

1. 字段上移

   • 如果两个子类拥有相同的字段，则将该字段移至超类。
   • 如果这些字段是private的，你必须将超类的字段声明为protected，这样子类才能引用它。

2. 将函数上移

   • 有些函数在各个子类中产生完全相同的结果，则将该函数移至超类。
   • 如果你使用的是一种强类型语言，而待提升函数又调用了一个只出现于子类而未出现于超类的函数，你可以在超类中为被调用函数声明一个抽象函数。

3. 构造函数本体上移
   如果在各个子类中拥有一些构造函数，并且它们的本体几乎完全一致。那么可以在超类中新建一个构造函数，并在子类构造函数中调用它。

4. 函数下移
   如果超类中的某个函数只与部分（而非全部）子类有关，则将这个函数移到相关的那些子类中去。

5. 字段下移
   超类中的某个字段只被部分（而非全部）子类用到，则将这个字段移到需要它的那些子类去。

6. 提炼子类
   如果类中的某些特性只被某些（而非全部）实例用到，则新建一个子类，将上面所说的那一部分特性移到子类中。

7. 提炼超类
   如果两个类有相似特性，则为这两个类建立一个超类，将相同特性移至超类。

8. 提炼接口
   如果某各类在不同环境下扮演截然不同的角色，使用接口就是个好主意。

9. 折叠继承体系
   如果超类和子类之间无太大区别，则将它们合为一体。

10. 塑造模板函数
    你有一些子类，其中相应的某些函数以相同的顺序执行类似的操作，但各个操作的细节上有所不同。将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。

11. 以委托取代继承

12. 以继承取代委托

第12章 大型重构

1. 梳理并分解继承体系
   • 如果某个继承体系同时承担两项责任，则可以建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
   • 要指出继承体系是否承担了两项不同的责任并不困难：如果继承体系中的某一特定层级上的所有类，其子类名称都以相同的形容词开始，那么这个体系可能就是承担着两项不同的责任。
2. 将过程化设计转化为对象设计
3. 将领域和表述/显示分离
   某些GUI类之中包含了领域逻辑，将领域逻辑分离出来，为它们建立独立的领域类。
4. 提炼继承体系
   如果你有某个类做了太多工作，其中一部分工作是以大量条件表达式完成的，那么可以建立继承体系，以一个子类表示一种特殊情况。

第13章 重构，复用与现实

1. 现实的检验
2. 为什么开发者不愿意重构他们的程序
3. 再论现实检验
4. 重构的资源和参考资料
5. 从重构联想到软件复用和技术传播

第14章 重构工具

1. 使用工具进行重构
2. 重构工具的技术标准
3. 重构工具的实用标准

第15章 总结

要点列表

1. 如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加新特性。
2. 重构前，先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
3. 重构技术就是以微小的步伐修改程序。如果你犯下错误，很容易便可发现它。
4. 任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀程序员。
5. 重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
6. 重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
7. 事不过三，三则重构
8. 不要过早发布接口。请修改你的代码所有权政策，使重构更顺畅。
9. 当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余。
10. 确保所有测试都完全自动化，让它们检查自己的测试结果。
11. 一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。
12. 频繁地运行测试。每次编译请把测试也考虑进去——每天至少执行每个测试一次。
13. 每当你收到bug报告，请先写一个单元测试来暴露这只bug。
14. 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。
15. 考虑可能出错的边界条件，把测试火力集中在那儿。
16. 当事情被大家认为应该会出错时，别忘了检查是否抛出了预期的异常。
17. 不要因为测试无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。

对于比较简单或者笔者暂时还没有很好理解的部分，只是一笔带过；而对于笔者在工作中遇到过相似问题的地方，则摘录地比较详细。《重构：改善代码的既有设计》一书非常经典，需要阅读、实践、再阅读、再实践。如果你也是一个注重代码简洁、美观和高效的程序员，那么这本书一定不能错过，深入阅读一定能提升代码的质量。本文会在后续继续更新完善，剔除简单和不常用的部分，完善和保留实用的部分。

本文作者： Sheh伟伟
本文链接： http://davidsheh.github.io/2016/03/03/「重构：改善代码的既有设计」读书笔记/
版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处！