《重构-改善既有代码的设计》读书笔记

03.25-03.30、04.02-04.04、04.48

03.25 周日
第一章重构，改善既有代码的设计
1.任何不被修改的变量都可被我当成参数传入新的函数，至于会被修改的变量就需格外小心。如果只有一个变量会被修改，我可以把它当作返回值。
2.任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀额程序员。
感想：排版看得很难受，因为作者将代码对比，但是放在不同页对比，不利于阅读。

03.26 周一
第二章重构原则
1.重构：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
2.当人们只为短期目的，或是在完全理解整体设计之前，就贸然修改代码，程序将逐渐失去自己的结构，就贸然修改代码，程序将逐渐失去自己的结构，程序员愈来愈难通过阅读源码而理解原来的设计。
3.在非对象数据库中，解决这个问题（数据迁移）的办法之一就是：在对象模型和数据库模型之间插入一个分割层，这就可以隔离两个模型各自的变化。升级某一模型时无需同时升级另一模型，只需升级上述的分割层即可。这样的分割层会增加系统复杂度，但可以给你带来很大的灵活度。
感想：可以通过重构他人的代码，帮助理解。

03.27 周二
第三章代码的坏味道
1.Duplicated Code（重复代码）
使用Pull Up Method（上移函数），Extract Method（提取函数），将相同的函数提取到超类。
2.Long Method（过长函数）
对长函数提炼，提炼过程中如果有大量参数和临时变量，运用Replace Temp with Query（查询替换临时变量）来消除这些临时元素。Introduce Parameter Object（引入参数对象）和Preserve Whole Object（保持对象完整）可以将过长的参数列表变得简洁一些。仍然有太多临时变量和参数，可以用Replace Method with Method Object(以函数对象取代函数)。可以使用Decompose Conditional（分解条件表达式）处理条件表达式。
想法:
（1）引入参数对象，举个例子：原本需要传入一个人的性别，姓名，年龄等十个相关参数，其实只需传入Person类即可。
（2）以函数对象取代函数，将一个复杂方法放进一个新类的compute（）中，复杂的参数列表作为构造函数的参数，调用新类的compute（）方法即可，这样在调用时不会有复杂的参数列表。
3.Large Class（过大的类）
使用提取类或者Extract Subclass（提取子类）。对一个有太多代码的类：先确定客户端如何使用它们，然后运用Extract Interface（提取接口）为每一种使用方式提炼出一个接口。如果过大的类是个GUI类，可以使用Duplicate Observed Data（复制被监视数据）。
想法：
（1）提取子类：你发现类中的某些行为只被一部分实例用到，其他实例不需要它们。那可以让这些行为放在子类中。

03.28 周三
继续第三章
4.Long Parameter List（过长参数列）
如果向已有的对象发出一条请求就可以取代一个参数，那么你应该可以激活重构手法Replace Parameter with Method（以函数取代参数）。
5.Divergent Change（发散式变化）
将因为某特定原因而造成的所有变化，运用Extract Class（提炼类）将他们提炼到另一个类中。
6.Shotgun Surgery（霰弹式修改）
如果需要修改的代码散布四处，你不但很难找到他们，也很容易忘记某个重要的修改。这种情况应该使用Move Method（搬移函数）和Move Field（搬移字段）把所有需要修改的代码放进同一个类。如果眼瞎没有合适的类可以放置这些代码，就创造一个。通常可以运用Inline Class（将类内联化）把一系列相关行为放进同一个类。这可能会造成少量的发散式变化，但你可以轻易处理它。
5和6的区别：5发散式变化是指“一个类受多种变化的影响”，6霰弹式修改则是指“一种变化引发多个类相应修改”。
7.Feature Envy（依恋情结）
有一种经典气味是：函数对某个类的兴趣高过对自己所处类的兴趣。这种孺慕之情最通常的焦点便是数据。无数次经验里，我们看到某个函数为了计算某个值，从另一个对象那儿调用几乎半打的取值函数。疗法显而易见：把这个函数移至另一个地点。你应该使用搬移函数把它移到该去的地方。有时候函数中只有一部分受这种依恋之苦，这时候你应该使用提取函数把这一部分提炼到独立函数中，再使用搬移函数带它去它的梦中家园。
8.Data Clumps（数据泥团）
两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。首先请找出这些数据以字段形式出现的地方，运用提取类将它们提炼到一个独立对象中。然后将注意力转移到函数签名上，运用引入参数对象或保持对象完整为它减肥。这么做的直接好处是可以将很多参数列缩短，简化函数调用。不必在意只用上新对象的一部分字段，只要以新对象取代两个或者更多字段，就是值得的。
9.Primitive Obsession（基本类型偏执）
对象技术的新手通常不愿意在小任务上运用小对象——像是结合数值和币种的money类。你可以运用Replace Data Value with Object（以对象取代数据值）将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。如果想要替换的数据值是类型吗，而它并不影响行为，则可运用Replace Type Code with Class（以类取代类型码）将它换掉。如果你有与类型码相关的条件表达式，可运用Replace Type Code with Subclass（以子类取代类型码）或Repalce Type Code with State/Strategy（以State/Strategy取代类型码）加以处理。
如果你有一组应该总是被放在一起的字段，可运用Extract Class。如果你在参数列中看到基本型数据，试试Introduce Parameter Object。如果你发现自己正从数组中挑选数据，可运用Replace Array with Object（以对象取代数组）。
10.Switch Statements（switch惊悚现身）
一看到switch应该可以考虑以多态替换。
如果只是在单一函数中有些选择实例，且并不想改动它们，那么用多态有些浪费，可以使用Replace Parameter with Explicit Methods（以明确函数取代参数）。如果选择条件之一是null，可以试试Introduce Null Object（引入Null对象）。Replace Conditional with Polymorphism（以多态取代条件表达式）。
11.Parallel Inheritance Hierarchies（平行继承体系）
消除重复性的策略：让一个继承体系的实例引用另一个继承体系的实例。
12.Lazy Class（冗赘类）
如果某些子类没有做足够的工作，试试Collapse Hierarchy（折叠继承体系）。对于几乎没用的组件，你应该以内部类对付它们。
13.Speculative Generality（夸夸其谈未来性）
如果你的某个抽象类其实没有太大作用，请运用折叠继承体系。不必要的委托可运用将类内联化除掉。如果函数的某些参数未被用上，可对它实施Remove Parameter（移除参数）。如果函数名词代有多余的抽象意味，应该对它实施Rename Method（方法重命名）。
想法：不要为还未发生的非必要的事情写代码。
14.Temporary Field（令人迷惑的暂时字段）
将对象中只有特定情况才用上的变量与对象分离。
15.Message Chains（过度耦合的消息链）
如果一旦对象间的关系发生任何变化，客户端就不得不做出相应修改，应该使用Hide Delegate（隐藏委托关系），可以在消息链的不同位置进行这种重构手法。
16.Middle Man（中间人）
过度委托需要Remove Middle Man（移除中间人）。InlineMethod（内联方法）、Replace Delegation with Inheritance（以继承取代委托）。
17.Inappropriate Intimacy（狎昵关系）
减弱过分的狎昵关系，可以使用Change Bidirectional Association to Unidirectional（将双向关联改为单向）。
18.Alternative Classes with Different Interfaces（异曲同工的类）
重新命名。
19.Incomplete Library Class（不完美的类库）
如果只修改库类的一两个函数，可以运用Introduce Foreign Method （引入外加函数）。如果想要添加一大堆额外行为，就得运用Introduce Local Extension（引入本地扩展）。
20.Data Class（纯稚的数据类）
运用Encapsulate Field（自封装字段）将纯稚的数据类的public字段封装。类内容器类的字段，运用Encapsulate Collection（封装群集）把他们封装起来。对于不该被其他类修改的字段，请使用Remove Setting Method（移除设置函数）。Hide Method（隐藏函数）。
21.Refused Bequest（被拒绝的遗赠）
继承体系设计错误时，为子类新建兄弟类，运用Push Down Method（函数下移）和Push Down Field（字段下移）把所有用不到的函数下推给兄弟。Replace Inheritance with Delegation （以委托取代继承）。
22.Comments（过多的注释）
过多的注释不表示注释不好，而可能表示因为程序不好所以需要很多注释来解释。重构程序后，将注释减小到适当大小。

想法：第三章有20小节，介绍了20种代码坏味道，就这些详细概述就可以出本书了。但其中很多坏味道是相同的，所以这章适合比较快速阅读，之后在遇到对应问题的时候再回顾。这章的很多重构手法，保留了原文（英文），需要对提及的所有重构手法记下、翻译并记住。

03.29
第四章构筑测试体系
1.确保所有测试都完全自动化，让它们检查自己的测试结果。
2.一套测试就是一个强大的bug侦测器，能够大大缩减查找bug所需要的时间。
3.使用JUnit测试框架
4.频繁地运行测试，每次编译请把测试也考虑进去——每天至少执行每个测试一次。
4.JUnit框架的用途是单元测试，编写这些测试的目的是为了提高程序员的生产率。单元测试是高度局部化的东西，每个测试类都隶属于单一包，它能够测试其他包的接口，除此之外它将假设其他包一切正常。功能测试用来保证廉能够正常运作，它们从客户的角度保障质量，由独立团队使用重量级工具和技术来帮助自己开发良好的功能测试。一般而言，功能测试尽可能把整个系统当作一个黑箱。
5.每当你收到bug报告，请先写一个单元测试来暴露bug。
6.编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。（其实做很多事，与其希望每一步都完美而拖着没做，不如先完成它）
7.考虑可能出错的边界条件，把测试火力集中在那儿。
8.当事情被认为应该会出错时，别忘了检查是否抛出了预期的异常
9.当测试数量达到一定程度之后，继续增加测试带来的效益就会呈现递减态势，而非持续递增；如果视图编写太多测试，你也可能因为工作量太大而气馁，最后什么也写不成。
10.不要因为无法捕捉所有bug就不写测试，因为测试的确可以捕捉到大多数bug。

想法：单元测试是对重构的一种帮助。

第五章重构列表
1.重构的记录格式
–名称
–简短概要：简单介绍重构手法的适用场景，以及它所做的事情。这部分可以帮助你更快找到你所需要的重构手法。
–动机：为什么需要重构、什么情况下不使用这个重构
–做法：如何重构
–范例

（本书基于java1.1）

第六章重新组织函数
6.1提炼函数
1.对简单语句和语句的简单注释，将它们提炼到一个函数中，并起一个适合的函数名，使看函数名即可以清楚函数作用。
2.一个变量在被提炼代码段内外都被用到，必须让提炼出的新函数返回它。
6.2内联函数
1.看代码的话，作者将函数移除了，但如果函数调用点是个比较复杂的式子的话，可能用函数反而更好。所以这是一个度的问题。

6.3内联临时变量
1.一个临时变量，只被一个简单表达式赋值一次，而它妨碍了其他重构手法，那么将所有对该变量的引用动作，替换为对它赋值的那个表达式自身。
疑问：如果这个表达式使用很多，也这样做吗？
6.4以查询取代临时变量
1.一个临时变量保存某一表达式的运算结果，将这个表达式提炼到一个独立函数中。将这个临时变量的所有引用点替换为对新函数的调用。此后，新函数就可被其他函数使用。
6.5引入解释性变量
1.如果有一个复杂的表达式，将该表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途。
6.6分解临时变量
1.程序有某个临时变量被赋值超过一次，它既不是循环变量，也不被用于收集计算结果。针对每次赋值，创造一个独立、对应的临时变量。
想法：这样会创造更多的变量，但如果代码需要修改这些变量，耦合性比以前低的优点就显现出来，并且代码阅读者不容易迷惑。
6.7移除对参数的赋值
1.代码对一个参数进行辅助，以一个临时变量取代该参数的位置。
想法:这小节还讲了java传参，要记住传参一律传递参数的副本。
6.8以函数对象取代函数
1.你有一个大型函数，其中对局部变量的使用使你无法采用提取函数。将这个函数放进一个单独对象中，如此一来局部变量就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。
6.9替换算法
1.你想要把某个算法替换为另一个更清晰的算法：将函数本体替换为另一个算法。

想法：这章围绕对重新组织函数讲述了一些重构方法，非常详细描述了做法。

第七章在对象之间搬移特性
7.1搬移函数
情景（简短概要）：你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或者后者调用。
做法：在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是将旧函数完全移除。
7.2搬移字段
简短概要：你的程序中，某个字段被其所驻类之外的另一类更多地用到。
做法：在目标类新建一个字段，修改源字段的所有用户，令它们改用新字段。
7.3提炼类
简短概要：某个类做了应该由两个类做的事。
做法：建立一个新类，将相关的字段和函数从旧类搬移到新类。
7.4将类内联化
简短概要：某个类没有做太多事情。
做法：将这个类的所有特性搬移到另一个类中，然后移除原类。
7.5隐藏委托关系
简短概要：客户通过一个委托类来调用另一个对象。
做法：在服务类上建立客户所需的所有函数，用以隐藏委托关系。

03.30
7.6移除中间人
简短概述：某个类做了过多的简单委托工作。
做法：让客户直接调用受托类。

7.7引入外加函数
简单概述：你需要为提供服务的类增加一个函数，但你无法修改这个类。
做法：在客户类中建立一个函数，并以第一参数形式传入一个服务类实例。
Date newStart = new Date(previousEnd.getYear(),previousEnd.getMonth(),previousEnd.getDate()+1);
–>
Date newStart = nextDay(previousEnd);
private static Date nextDay(Date arg){
return new Date(arg.getYear(0,arg.getMonth(),arg.getDate()+1);
}
7.8引入本地扩展
简单概述：你需要为服务类提供一些额外函数，但你无法修改这个类。
做法：建立一个新类，使它包含这些额外函数。让这个扩展品成为源类的子类或包装类。

想法：相对于第六章在函数间搬移，第七章则是在对象间搬移，避免一个类承担过多责任。

第八章重新组织数据
8.1自封装字段
简短概述：你直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙。
做法：为这个字段建立取值/设值函数，并且只以这些函数来访问字段。
动机：间接访问变量，子类可以通过覆写一个函数而改变获取数据的途径：它还支持更灵活的数据管理方式，例如延迟初始化。直接访问变量，代码比较容易阅读。
8.2以对象取代数据值
简短概述：你有一个数据项，需要与其他数据和行为一起使用才有意义。
动机：将数据线变成对象。
8.3将值对象改为引用对象。
简短概述：你从一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象。
做法：将这个值对象变成引用对象。
想法：让一个类始终只有一个实例，常说的懒汉式、饿汉式
8.4将引用对象改为值对象
简短概述：你有一个引用对象，很小且不可变，而且不易管理。
做法：将它变成一个值对象。
8.5以对象取代数组
简短概述：你有一个数组，其中的元素各自代表不同的东西。
做法：以对象替换数组。对于数组中的每个元素，以一个字段来表示。
8.6复制被监视数据
简短概述：你有一些领域数据置身于GUI控件中，而领域函数需要访问这些数据。
做法：将该数据复制到一个领域对象中。建立一个Observe模式，用以同步领域对象和GUI对象内的重复数据。
8.7将单向关联改为双向关联
简短概述：两个类都需要使用对方特性，但其间只有一条单向连接。
做法：添加一个反向指针，并使修改函数能够同时更新两条连接。

04.02
8.8将双向关联改为单向关联
简短概述：两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。
做法：去除不必要的关联。
8.9以字面常量取代魔法数
简短概述：你有一个字面数值，代有特别含义。
做法：创造一个常量，根据其意义为它命名，并将上述的字面数值替换为这个常量。
科普：魔法数是历史最悠久的不良现象之一。所谓魔法数是指拥有特殊意义，却又不能明确表现出这种意义的数字。如果你需要在不同的地点引用同一个逻辑数，魔法数会让你烦恼不已，因为一旦这些数发生改变，你就必须在程序中找到所有魔法数，并将它们全部修改一遍。
8.10封装字段
简单概述：你的类中存在一个public字段。
做法：将它声明为private，并提供相应的访问函数。
8.11封装集合
简短概述：有个函数返回一个集合。
做法：让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数。
8.12以数据类取代记录
简单概述：你需要面对传统编程环境中的记录结构。
做法：为该记录创建一个“哑”数据对象。
8.13以类取代类型码
简短概述：类之中有一个数值类型码，但它并不影响类的行为。
做法：以一个新的类替换该数值类型码。
8.14以子类取代类型码
简短概述：你有一个不可变的类型码，它会影响类的行为。
做法：以子类取代这个这个类型码
8.15以State/Strategy取代类型码
简短概述：你有一个类型码，它会影响类的行为，但你无法通过继承手法消除它。
做法：以状态对象取代类型码。
想法：以类取代类型码比较常见，另两种比较少见。但如果真的因为类型码而决定产生什么样的类，可以考虑使用。

04.03
8.16以字段取代子类
简短概述：你的各个子类的唯一差别只在“返回常量数据”的函数身上。
做法：修改这些函数，使它们返回超类中的某个（新增）字段，然后销毁子类。
想法：像这种理解起来很容易的重构，可以快速检阅

第九章简化条件表达式
9.1分解条件表达式
简短概述：你有一个复杂的条件（if-then-else)语句。
做法：从if、then、else三个段落中分别提炼出独立函数。
想法：看了例子，我觉得吧，还是‘度’的问题，掌握好度。
9.2合并条件表达式
简短概述：你有一系列条件测试，都得到相同结果。
做法：将这些测试合并为一个条件表达式，并将这个条件表达式提炼成为一个独立函数。
难易度：1
想法：太过简单..甚至不了解重构的人也会这么做。最多也就是要明白逻辑与、逻辑或、三元表达式。
9.3合并重复的条件片段
简单概述：在条件表达式的每个分支上有着相同的一段代码。
做法：将这段重复代码搬移带条件表达式之外。
难易度：1
9.4移除控制标记
简短概述：在一系列布尔表达式中，某个变量带有“控制标记”的作用。
做法：以break语句或return语句取代控制标记。
难易度：1
9.5以卫语句取代嵌套条件表达式
简短概述：函数中的条件逻辑使人难以看清正常的执行路径。
做法：使用卫语句表现所有特殊情况。
难易度：1.5
想法：如果在条件判断后就是return，使用起来确实能提升可读性。
科普：如果某个条件极其罕见，就应该单独检查该条件，并在该条件为真时立刻从函数中返回。这样的单独检查常常被称为“卫语句”。
9.6以多态取代条件表达式
简短概述：你手上有个条件表达式，它根据对象类型的不同而选择不同的行为。
做法：将这个条件表达式的每个分支放进一个子类内的覆写函数中，然后将原始函数声明为抽象函数。
难易度：2
想法：原本由switch选择的，改由多态自动匹配。同一个函数名，参数列表不一样。
9.7引入Null对象
简短概述：你需要再三检查某对象是否为null。
做法：将null值替换为null对象。
难易度：2.5
想法：当检查对象（而不是检查对象的字段）是否为null，将对象指向对象的子类（空对象）。这之后，不用重复判断是否为空了。
9.8引入断言
简短概述：某一段代码需要对程序状态做出某种假设。
做法：以 断言明确表现这种假设。
难易度：1
想法：在交流的角度上，断言可以帮助程序阅读者理解代码所做的假设；在调试的角度上，断言可以在距离bug最近的地方抓住它们。

第十章简化函数调用
10.1函数改名
简短概述：函数的名称未能揭示函数的用途。
做法：修改函数名称。
难易度：1
10.2增加参数
简短概述：某个函数需要从调用端得到更多信息。
做法：为此函数添加一个对象参数，让该函数带进函数所需信息。
难易度：1
10.3移除参数
简短概述：函数本体不再需要某个参数。
做法：将该参数去除。
难易度：1
10.4将查询函数和修改函数分离
简短概述：某个函数既返回对象状态值，又修改对象状态。
做法：建立两个不同的函数，其中一个负责查询，另一个负责修改。
难易度：2
想法：例子不是很清晰..
10.5令函数携带参数
简短概述：若干函数做了类似的工作，但在函数本体中却包含了不同的值。
做法：建立单一函数，以参数表达那些不同的值。
难易度：1.5
10.6以明确函数取代参数
简短概述：你有一个函数，其中完全取决于参数值而采取不同行为。
做法：针对该参数的每一个可能值，建立一个独立函数。
难易度：1

04.04
10.7保持对象完整
简短概述：你从某个对象中取出若干值，将它们作为某一次函数调用时的参数。
做法：改为传递整个对象。
难易度：1
10.8以函数取代参数
简短概述：对象调用某个函数，并将所得结果作为参数，传递给另一个函数。
而接受该参数的函数本身也能够调用前一个函数。
做法：让参数接受者去除该项参数，并直接调用前一个函数。
难易度：1.5
10.9引入参数对象
简短概述：某些参数总是很自然地同时出现。
做法：以一个对象取代这些参数。
难易度：1.5
10.10移除设置函数
简短概述：类中的某个字段应该在对象创建时被设值，然后就不再改变。
做法：去掉该字段的所有设值函数。
难易度：1
10.11隐藏函数
简短概述：有一个函数，从来没有被其他任何类用到。
做法：将这个函数修改为private。
难易度：1
10.12以工厂函数取代构造函数
简短概述：你希望在创建对象时不仅仅是做简单的建构动作。
做法：将构造函数替换为工厂函数。
难易度：2
10.13封装向下转型
简短概述：某个函数返回的对象，需要由函数调用者
做法：将向下转型动作移到函数中。
难易度：1.5
10.14以异常取代错误码
简短概述：某个函数返回一个特定的代码，用以表示某种错误情况。
做法：改用异常。
难易度：1.5
10.15以测试取代异常
简短概述：面对一个调用者可以预先检查的条件，你抛出了一个异常。
做法：修改调用者，使它在调用函数之前先做检查。
难易度：1.5

第十一章处理概括关系
11.1字段上移
简短概述：两个子类拥有相同的字段。
做法：将该字段移至超类。
难易度：1
11.2函数上移
简短概述：有些函数，在各个子类中产生完全相同的结果。
做法：将该函数移至超类。
难易度：1
11.3构造函数本体上移
简短概述：你在各个子类中拥有一些构造函数，它们的本体几乎完全一致。
做法：在超类中新建一个构造函数，并在子类构造函数中调用它。
难易度：1
11.4函数下移
简单概述：超类中的某个函数只与部分（而非全部）子类有关。
做法：将这个函数移到相关的那些子类去。
难易度：1
11.5字段下移
简短概述：超类中的某个字段只被部分（而非全部）子类用到。
做法：将这个字段移到需要它的那些子类去。
难易度：1
11.6提炼子类
简短概述：类中的某些特性只被修鞋（而非全部）实例用到。
做法：新建一个子类，将上面所说的那一部分特性移到子类中。
难易度：2
11.7提炼超类
简短概述：为这两个类建立一个超类，将相同特性移至超类。
做法：为这两个类建立一个超类，将相同特性移至超类。
难易度：2
11.8提炼接口
简短概述：若干客户使用类接口中的同一子集，或者两个类的接口有部分相同。
做法：将相同的子集提炼到一个独立接口中。
难易度：2
11.9折叠继承体系
简短概述：超类和子类之间无太大区别。
做法：将它们合为一体。
难易度：1
11.10塑造模板函数
简短概述：你有一些子类，其中相应的某些函数以相同顺序执行类似的操作，但各个操作的细节上有所不同。
做法：将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。
难易度：1.5
想法：这次只看简短概述难以理解，需要看图理解。

04.08
11.11以委托取代继承
简短概述：某个子类只使用超类接口中的一部分，或者根本不需要继承而来的数据。
做法：在子类中新建一个子类用以保存超类；调整子类函数，令它改而委托超类；然后去掉两者之间的继承关系。
难度：2
11.12以继承取代委托
简短概述：你在两个类之间使用委托关系，并经常为整个接口编写许多极简单的委托函数。
做法：让委托类继承受托类。
难度：2
想法：如果发现需要使用受托类中的所有函数，并且费了很大力气编写所有极简的委托函数，使用这个重构方法。

第十二章大型重构
1.由于大型重构可能需要花费相当长的时间，因此它们并不像其他章节介绍的重构那样，能够立刻让人满意，你必须有那么一点小小的信仰：你每天都在使你自己的程序世界更安全。
12.1梳理并分解继承体系
简短概述：某个继承体系同时承担两项责任。
做法：建立两个继承体系，并通过委托关系让其中一个可以调用另一个。
难度：2.5
12.2将过程化设计转化为对象设计
简短概述：你手上有一些传统过程化风格的代码。
做法：将数据记录变成对象，将大块的行为分成小块，并将行为移入相关对象之中。
难度：1.5
12.3将领域和表述/显示分离
简短概述：某些GUI类之中包含了领域逻辑。
做法：将领域逻辑分离出来，为它们建立独立的领域类。
12.4提炼继承体系
简短概述：你有某个类做了太多工作，其中一部分工作是以大量条件表达式完成的。
做法：建立继承体系，以一个子类表示一种特殊情况。
难度：1.5

第十三章重构，复用与现实
13.1现实的检验
重构既关注面向对象技术、又关注变化过程和软件进化支持技术。
13.2为什么开发者不愿意重构他们的程序
1.当需要对既有软件进行扩展，对所做的事情没有完整的了解，受到生产进度的压力，如何应对？
–重写整个程序
–赋值、修改现有系统的一部分
–重构
2.重构使得设计思路更详尽明确。重构被用于开发框架、抽取可复用组件、使软件架构更清晰、使新功能的增加更容易。重构可以帮助你充分利用以前的投资，减少重复劳动，使程序更加简洁有力。
3.不肯重构的原因
–你不知道如何重构
–如果这些利益是长远的，何必现在付出这些努力呢？长远来看，说不定当项目收获这些利益时，你已经不在职位上了。
–代码重构是一项额外工作，老板付钱给你，主要是让你编写新功能。
–重构可能破坏现有程序
4.针对3的几个问题
（1）如何重构，在哪里重构
根据常见的重构原因，对需要重构的地方重构。另外也可以使用自动化工具，但经验才是最重要的。自动化工具可用来识别程序中的结构缺陷，例如函数参数过多、函数过长等。这些都应该考虑成为重构的对象。自动化工具还可以识别结构上的相似，这样的相似很可能代表着冗余代码的存在。
（2）重构以求短期利益
重构明显有中长期利益，但同时也存在短期利益。短期来看，如果在测试阶段发现共同的代码有错误，只需在一个地方修改就行了。代码总量变少了。
（3）降低重构带来的开销
目前已有一些工具和技术，可以使重构快速而相对无痛苦地完成。
一些面向对象程序员的经验显示，重构虽然需要开销，但它能在程序开发的其他阶段降低精力和时间开销，从而补偿它的开销。
尽管乍见之下重构有可能有点笨拙、开销太大，但是当它成为软件开发规则的一部分，人们就不会再觉得它费事，反而开始觉得它是必不可少的。
（4）安全地进行重构
重构工具的一部分是程序分析器，这是一个用来分析程序结构的程序。这个工具可以解答一系列问题，内容涉及作用域、类型和程序语义等方面。安全性检查可以在重构工具中实现。

第十四章重构工具
1.使用工具进行重构
Refactoring Browser
2.以Eclipse和IntelliJ为代表的现代Java IDE已经提供了相当强大的自动化重构功能。

第十五章总结
如何学习
随时挑一个目标
没把握就停下来
学习原路返回
二重奏

要点列表-440页