我的心路历程

今天开始学习《重构改善既有代码的设计》这本书。我首先翻阅了前言部分，书中写了什么是重构。什么是重构？

我的思考心路：
对于重构的认识，我认为程序开发并不是一个设计后即动作的行为，它需要在开发过程中持续整理程序，最大限度减少引入错误的概率的过程。

继续翻阅前言，书中写了本书有什么。告诉了书本的章节对应内容。第1章是一个重构的Demo，第2章是重构的原则定义，第3章是“坏代码”的味道，第5-12章是核心部分——重构的一些手法，等等。从哪开始快速入手看呢？

我的思考心路：
翻开第1章，我了解到这个Demo主要是个影片出租店程序，程序的功能是计算顾客消费金额并打印详单。翻看了第1章目录：起点–重构第一步–分解并重组statement()–运用多态取代与价格相关的逻辑条件–结语。我看看结语讲了什么？

翻阅结语，结语中表示第一章的Demo示范了数个重构手法。重构后的程序使责任分配更合理，这种风格，将迥异于过程化风格，也使码农难以再满足于结构化风格。看看Demo示范了那几个重构手法？

Demo中重构手法有：
P110 提炼函数
P142 搬移函数
P255 以多态取代条件表达式
P171 自封装字段
P227 以state/strategy取代类型码

我的学习概括

Extract Method（提炼函数）

动机*–做法

我自己的理解如下：
概念：
这个手法做法是，把可以被组织到一起的代码提炼到一个独立函数中，并用名称来表示用途。

应用场景：

1. 过长的函数。
2. 需要注释才能理解用途的代码。

达到目的：
得到简短而命名良好的函数。

优势：

1. 函数粒度小，复用机会大，且覆写更容易。
2. 使高层函数读起来像一系列注释。

动机–做法*

我自己的理解如下：
做法简图：

结合上图，我的关注点如下：

copy过程中注意安全：

1. 源函数层面：注意考虑变量、参数的作用域
2. 提炼出的代码层面：临时变量问题

意外1:
源函数中变量、参数的作用域与新函数不一致。
措施：若是局部变量，新函数里传入这部分参数。

意外2:
copy过程中临时变量被修改了。
措施：将被提炼代码段处理为一个查询，将结果赋值给相关变量。

Move Method（搬移函数）

动机*–做法

我自己的理解如下：

概念简图：

概念：
类A中函数Fun a与类B有调用关系的情况下，Fun a最常引用的类B中建立类似形为Fun a`的新函数，则Fun a变成单纯的委托函数，或可完全移除Fun a。

应用场景：

1. 一个类有太多行为。
2. 或类与类之间有太多合作而形成高度耦合。

达到目的：
使系统中的类更简单，系统任务交付更干脆。

动机–做法*

我自己的理解如下：
做法简图：

结合上图，我的关注点如下：
移动路径方向：函数Fun a与对象B交流比自己对象A交流多，所以搬移方向往B合适。

搬移过程中注意安全：

1. 源类A的子类超类层面：若源类A的子类和超类，有函数Fun a的声明不能进行搬移。除非类B表现出多态性。

意外1:
新目标类B中缺少对A的引用机制。
措施：把源对象类A的引用当作参数，传给新目标类B的Fun a`。

意外2:
Fun a包含异常处理，搬移后出现异常处理异常。
措施：根据逻辑判断某个异常该由哪个类处理，若类A负责，则异常处理留在类A。

Replace Conditional with Polymorphism（以多态取代条件表达式）

动机*–做法

我自己的理解如下：

概念简图：

概念：
将条件表达式的每个分支放进一个子类的覆写函数中，然后将原始函数声明为抽象函数。

应用场景：
同一组表达式在程序多个地方出现。

优势：

1. 减少编写明显的条件表达式。
2. 使“类型码switch语句”、“基于类型名称的if-then-else语句”出现减少。
3. 避免条件表达式情况下，添加新类型时要更新所有表达式的缺点。
4. 降低系统各部分间的依赖。

动机–做法*

我自己的理解如下：

结合上面的概念简图，我的关注点如下：
替换过程中注意安全：

1. 多态性层面：必须有一个继承结构。它可以有2种选择来做到这个结构。一般情况下采取以子类取代类型码的方法。若出现对象已经创建后，要修改类型码；或者，要重构的类已经有子类，则采取以state/strategy取代类型码的方法。
2. 超类层面：超类中某些private可能需要声明为protected。另外，超类中容纳条件表达式的函数要声明为抽象函数。