重构改善既有代码的设计

重构是在不改变软件可观察行为的前提下改善其内部结构

1.重构第一个案例

重构步骤

写好测试,保证输入输出一致
提取冗长的switch
每次修改的篇幅尽量原子,更容易发现错误
重构时,变量改名也重要.
函数应该放在它所使用的数据的所属对象内
去除临时变量
对于常改复杂的switch,建立多态取代switch

2. 重构原则

重构: 对软件内部结果的一种调整,目的是在不改变软件可观察行为的前提下,提高其理解性,降低其修改成本

重构的意义

让代码更有结构性
消除重复代码
把设计模式看出来
重构帮助找到BUG
重构能提高编程速度

何时重构 : 随时随地的进行

基本情况是一下三种,但这三种基本伴随着项目生命周期

添加功能时 : 当我添加功能感觉到困难时,我就会尝试重构能否给我带来便利
修补错误时重构 : 当调试时无法理解代码,就用重构加深自己的理解,因为显然代码还不够清晰--没有清晰到让我一眼就看出BUG
复审代码时重构 :

重构的难点:

新旧接口: 尽量让旧接口调用新接口
数据库: 苦逼的数据迁移吧

3.代码的坏味道

重复代码
过长函数
过大的类
过长的参数列
发散式修改 : 一个类收多个变化影响
散弹式修改 : 一个变化引起多个类响应修改
依恋情结: Model和Controller结合在一起
基本类型偏执: 当有多组基本类型经常出现在一起,应该包装程磊
switch惊悚现身
平行继承体系: 当你要增加一个子类,相对应要在别的地方增加一个子类
冗余类: 多余的类
夸夸其谈未来性
临时字段
过度耦合的消息链
中间人: 过度使用委托,当一个类的接口一般函数都委托给其他类.
Inappropriate Intimacy: 当子类对父类的了解总是超过后者的主观愿望,就把他移出继承
异曲同工类: 实现类似功能的代码
不完美的类库: 类库出现满足不我们的需求,需要进行大量修改从而达到目的时
纯字段而无作用的类
被拒绝的遗赠: 子类只使用极少的父类功能
过多的注释

4.构筑测试体系

测试: 测试你最担心出错的部分

5. 重构列表

以下就是我的重构手法了

6. 重新组织函数

6.1 Exract Method (提炼函数)

要诀就是短短短,一个函数实现的功能尽量原子化.

动机:

被复用机会大

做法:

如果想不出有意义的函数名,就别动了

6.2 Inline Method (内联函数)

当一个函数的本体与名称同样清楚易懂时

发现内部代码和函数名称同样清晰易读,非必要的间接性调用.

6.3 Inline Temp (内联临时变量)

你有一个临时变量,只被一个简单的表达式赋值一次,而它妨碍了其他重构手法

6.4 Replace Temp with Query (以查询取代临时变量)

将这个表达式提炼到一个独立函数中,将这个临时变量的所有引用点替换为对新函数的调用,此后新函数就可被其他函数使用

6.5 Introduce Explaining Variable (引入解释性变量)

将复杂的表达式的结果放入一个临时变量中,以变量名来解释表达式用途

6.6 Split Temporary Variable (分解临时变量)

一个变量只应该负责一个用途

6.7 Remove Assignments toPrameters (移除对参数赋值)

不要对代码参数进行赋值

6.8 Replace Method with Method Object (以函数对象取代函数)

有一个大型函数,其中对局部变量的使用使你无法采用提炼函数

步骤

建立一个新类,根据待处理函数的用途,为这个类命名
在新类中建立一个final字段,用以保存原先大型函数所在的对象。我们将这个字段称为"源对象",同时针对原函数的每个临时变量和每个参数,在新类中建立一个对应的字段保存
在新类中创建一个构造函数,接受源对象及原函数的所有参数作为参数
新建建立compute函数,将原函数的代码复制到compute函数中。如果需要调用源对象的任何函数,请通过源对象字段调用

6.9 Substitute Algorithm (替换算法)

更好的实现方案

7. 在对象之间搬移特性

7.1 Move Method (搬移函数)

有个函数与其所驻类之外的另一个进行更多交流,调用后者,或被后者调用

或者说,这个函数应该在另外一个类中

7.2 Move Field (搬移字段)

某个字段被其他所驻类之外的另一个类更多地用到

7.3 Extract Class (提炼类)

某个类做了应该两个类做的事情

7.4 Inline Class (将类内联化)

某个类没有做太多的事情

7.5 Hide Delegate (隐藏委托关系)

客户通过一个委托类来调用另一个对象

7.6 Remove Middle Man (移除中间人)

某个类做了过多的简单委托动作

7.7 Introduce Foreign Method (引入外加函数)

你需要为提供服务的类增加一个函数,但你无法修改这个类

7.8 Introduce Local Extension (引入本地拓展)

你需要为服务类提供一些额外函数,但你无法修改这个类

8. 重新组织数据

8.1 Self Encapsulate Field (自封装字段)

你直接访问一个字段,但与字段之间的耦合关系逐渐变得笨拙

为了方便自己/子类对该属性进行特殊化处理

8.2 Replace Data Value with Object (以对象取代数据值)

你有一个数据项,与其他数据和行为一起使用才有意义

8.3 Change Value to Reference (将值对象改为引用对象)

你从一个类衍生出许多彼此相等的实例,希望他们替换为同一对象

8.4 Change Reference to Value (将引入对象改为值对象)

你有一个引用对象,很少且不可变,而且不易管理

8.5 Replace Array with Object (以对象取代数组)

你有一个数组,其中的元素各自代表不同的东西

8.6 Duplicate Observed Date (复制被监视的数据)

你有一些领域数据置身于GUI控件中,而领域函数需要这些数据

8.7 Change Unidirectional Association to Bidirectional (将单向关联改为双向关联)

两个类都需要双方的特性

做法

在被引用类中增加一个字段,用以保存反向指针
决定由哪个类: 引用端还是被引用端--控制关联关系
1. 如果是一对多的引用对象,那么就由多(因为其拥有一的单一引用)控制关联关系
2. 如果某个对象是另一个对象的部件,那么后者负责控制关联关系
3. 如果是多对多,则都可以
在被控制端建立一个辅助函数,其命名应该清楚指出它的有限用途
如果既有的修改函数在控制端,让他辅助更新反向指针
如果既有的修改函数在被控端,就在控制端建立一个控制函数,并让既有修改函数调用这个新建的控制函数

8.8 Change Bidirectional Association toUnidirectional (将双向关联改为单向关联)

两个类之间有双向关联,但其中一个类如今不需要另外一个类的特性

8.9 Replace Magic Number with Symbolic Constant (以字面量取代魔法数)

8.10 Encapsulate Field (封装字段)

你的一个类存在publi字段

8.11 Encapsulate Collection (封装集合)

有个函数返回一个集合

让这个函数返回该集合的一个只读副本,并在这个类中提供添加/移除集合元素的函数

8.12 Replace Record with Data Class (以数据类取代记录)

你需要面对传统编程环境中的记录结构

为该记录创建一个'哑'数据对象

8.13 Replace Type Code with Class(以类取代类型码)

类之中有一个数值类型码,但它并不影响类的行为

8.14 Replace Type Code with Subclasses(以子类取代类型码)

你有一个不可变的类型码,它会影响类的行为

8.15 Replace Type Code with State/Strategy(以State/Strategy取代类型码)

8.16 Replace Sbuclass with Fields(以字段取代子类)

你的各个子类的唯一差别只在返回常量数据的函数身上

9 简化条件表达式

9.1 Decompose Conditional(分解条件表达式)

你有一个复杂的条件语句

做法

将if提炼出来为函数

9.2 Consolidate Conditional Expression(合并条件表达式)

你有一系列条件测试,都得到相同的结果

9.3 Consolidate Duplicate Conditional Fragments (合并重复的条件片段)

在条件表达式的每个分支上有着相同的一段代码

9.4 Remove Control Flag(移除控制标记)

在一系列布尔表达式中,某个变量带有控制标记的作用

9.5 Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件表达式)

函数中的条件逻辑使人难以看清正常的执行路径

9.6 Replace Conditional with Polymorphism (以多态取代条件表达式)

你手上有个条件表达式,它根据对象类型的不同选择不同的行为

9.7 Introduce Null Object(引入NULL)

你需要再三检查某对象是否为NULL

9.8 Introduce Assertion (引入断言)

某一段代码需要对程序状态做出某种加上

就是在函数刚开始,就把不可能往下执行的可能性干掉

10 简化函数调用

10.1 Rename Method (函数改名)

先想怎么给函数写注释
然后根据注释命名函数

10.2 Add Parameter(添加函数)

某个函数需要从调用端得到更多信息

10.3 Remove Parameter (移除参数)

函数本地不再需要某个参数

10.4 Separate Query from Modifier(将查询函数和修改函数分离)

某个函数即返回对象状态值,又修改对象状态

10.5 Parameter Method(令函数携带参数)

若干函数做了类似的工作,但在函数本体中却包含了不同的值

10.6 Replace Parameter with Explicit Methods(以明确函数取代参数)

你有一个函数,其中完全取决于参数值而采取不同的行为

10.7 Preserve Whole Object(保持对象完整)

你从某个对象取出若干值,将他们作为某一次函数调用时的参数

10.8 Replace Parameter with Methods(以函数取代参数)

对象调用某个函数,并将所得结果作为参数,传递给另一个参数,而接受该参数的函数本身也能够调用前一个函数

10.9 Introduce Parameter Object(引入参数对象)

某些参数总是很自然的同时出现

10.10 Remove Setting Method(移除设值函数)

类中的某个字段应该在对象创建时被设值,然后就不再改变

10.11 Hide Method(隐藏函数)

有一个函数,从来没有被其他任何类用到,改为private

10.12 Replace Constructor with Factory Method(以工厂函数取代构造函数)

你希望在创建对象时,不仅仅是做简单的建构动作

10.13 Encapsulate Downcast (封装向下转型)

某个函数返回的对象,需要由函数调用者执行向下转型

10.14 Replace Error Code with Exception (以异常取代错误码)

决定受控异常还是非受控异常决定在于: 调用者是否有责任在取款之前检查存款余额,还是应该偶遇withdraw()函数复制检查

如果检查余额是调用者的责任,那么取款金额大于存款余额,是编程错误,应该抛出异常
如果是withdraw()复制检查余额,withdraw则有责任声明抛出异常,调用者只应注意异常即可,即tru-catch

10.15 Replace Exception with Test(以测试取代异常)

面对一个调用者可以预先检查条件,你抛出一个异常

11 处理概括关系

11.1 Pull Up Field(字段上移)

两个子类拥有相同的字段

11.2 Pull Up Method(函数上移)

有些函数,在各个子类中产生完全相同的结果

技巧: 当函数调用了子类的方法,而父类中没有,可以在父类中定义一个接口函数

11.3 Pull Up Constructor Body(构造函数本体上移)

你在各个子类中拥有一些构造函数,他们的本体几乎是一样的

在超类中新建一个构造函数,并在子类构造函数中调用她

11.4 Push Down Method(函数下移)

超类中的某个函数只与部分(而非全部)子类有关

11.5 Push Down Field (字段下移)

超类中的某个字段只被部分子类用到

11.6 Extract Subclass(提炼子类)

类中的某些特性纸杯某些实例用到

11.7 Extract Superclass(提炼超类)

两个类有相似的特性

为这两个类建立一个超类,将相同特性移至超类

11.8 Extract Interface(提炼接口)

若干客户使用接口中的同一子集,或者两个类的接口有部分相同

将相同的子集提炼到一个独立接口中

与提炼超类类似,但是接口只提炼方法

11.9 Collapse Hierachy(折叠继承体系)

超类和子类之间无太大区别

将他们合为一体

11.10 Form Template Method(塑造模板函数)(强烈推荐)

你有一些子类,其中相应的某些函数以相同顺序执行类似的操作,但各个操作的细节上有所不同

将这些操作分别放进独立的函数里,并保持他们都有相同的签名,于是原函数也就变得相同了,然后将相同函数上移到超类

做法

将各个子类中分解目标函数,使分解后的各个函数要不完全相同,要不完全不同
运用pull up method将各子类内完全相同的函数上移到超类
对于那些完全不同的函数实施Rename Method
将原函数上移到超类
其余子类相同做法

11.11 Replace Inheritaance with Delegation (以委托取代继承)

某个子类只使用超累接口的一部分,或者根本不需要继承而来的数据

在子类中新建一个字段用来保存超累,调用子类函数,令他改为委托超类,去掉两者之间的继承关系

做法

在子类中新建一个字段,使其引用超类的一个实例,并将它初始化为this(这样做,可以暂时同时使用继承和委托)
修改子类的所有函数,不要引用超类
去除继承,新建一个受委托类的对象赋值的受托字段
针对客户端所用的每一个超类函数,为它添加一个简单的委托函数

11.12 Replace Deletegation with Inheritance(以继承取代委托)

你在两个类之间使用委托关系,并经常为整个接口编写许多极简单的委托函数

让委托类继承于受托类

12 大型重构

如果你不能说服项目经理把系统停止两个月让你重构

你只能一点一点地做你的工作,今天一点点,明天一点点.

只在需要添加新功能或修补错误时才进行重构,不必以开设就完成整个系统的重构

重构程度只要满足其他任何就行了,反正明天你还可以回来重构

进行大型重构时,必须要整个开发团队建立共识,这是小型重构不需要的

只有持续而无处不在的重构才可能成功

12.1 Tease Apart Inheritance (梳理并分解继承体系)

某个继承体系同时承担两项责任

建立两个继承体系,并通过委托关系让其中一个可以调用另外一个

做法

识别出继承体系所承担的不同责任,建立一个二维/三维/思维表格
判断哪一项责任比较重要,先把他留在原先的继承体系中,准备将另一项责任放到另一个继承体系

12.2 Convert Design to Object (将过程设计转换为对象设计)

你手上有一些传统过程化风格的代码

将数据记录变成对象,将大块的行为分成小块,并将行为移入相关对象之中

12.3 Seprate Domain from Presentation (将领域和表述/显示分离)

将领域和显示分离

某些GUI类之中包含领域逻辑

将领域逻辑分离出来,为他们建立独立的领域类

12.4 Extract Hierachy(提炼继承体系)

你有某个类做了太多工作,其中一部分工作是以大量条件表达式完成的

建立继承体系,以一个子类表示一种特殊情况

13 重构,复用与实现

要解决的现实问题

程序员不知道如何重构
1. 开发新功能
2. 修补旧BUG
3. 代码开始发臭
如果重构利益是长远的,何必现在就付出努力呢,长远看来,说不定收益时,你已经不再职位上了
1. 一小步,一小步,开发新功能,重构旧代码
2. 修补旧BUG,重构旧代码
代码重构是额外的工作,老板给钱,主要是开发新功能
1. 修复BUG
重构可能破快现有程序
1. 测试用例

14 重构工具

请Google...这是几十年前的书了,工具不可能适用..

15 总结

你什么时候算会重构

当你面对别人留下杂乱代码,可以将它使他变好

好到可以继续后续的开发

重构 改善既有代码的设计