【笔记】《重构：改善既有代码的设计》第1章-重构，第一个案例

第1章 重构，第一个案例

1.1 起点

1.2 重构的第一步

第一个步骤永远相同：我得为即将修改的代码建立一组可靠的测试环境。

1.3 分解并重组statement()

长的离谱的statement()。代码块越小，代码的功能越容易管理，代码的处理和移动也就越轻松。

找出代码的逻辑泥团并运用Extract Method

我得在这段代码里找出函数内的局部变量和参数。不会被修改的变量都可以被我当成参数传入新的函数，至于会被修改的变量就需格外小心。如果只有一个变量会被修改，我可以把它当做返回值。

修改变量名称 代码的清晰度

搬移"金融计算"代码

函数应该放在它所使用的数据的所属对象内。 运用Move Method. 调整代码使之适应新家，然后重新编译

"适应新家"意味着要去掉参数。此外我还要在搬移时同时变更函数名称

下一个步骤是找出程序中对旧函数的所有引用点，并修改它们，让它们改用新函数

下一件事是去掉旧函数。

有时候我会保留旧函数，让它调用新函数。如果旧函数是一个public函数，我又不想修改其他类的接口，这便是一种有用的手法。

Replace Temp With Query。

我喜欢尽量除去这一类临时变量。临时变量往往引发问题，它们会导致大量参数被传来传去，而其实完全没有这种必要

提炼“常客积分计算”代码

Extract Method重构手法

去除临时变量

Replace Temp with Query，并利用查询函数（query method）来取代临时变量。

1.4 运用多态取代与价格相关的条件逻辑

问题的第一部分是switch语句。最好不要在另一个对象的属性基础上运用switch语句。如果不得不使用，也应该在对象自己的数据上使用，而不是在别人的数据上使用。

终于……我们来到继承

我们有数种影片类型，它们以不同的方式回答相同的问题。这听起来很像子类的工作。我们可以建立Movie三个子类，每个都有自己的计费法。

这样一来，我就可以用过多态来取代switch语句了。很遗憾的是这里有一个小问题，不能这么干。一部影片可以在生命周期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的类。不过还是有一个解决方法：State模式。

加入这一层间接性，我们就可以在Price对象内进行子类化动作，于是便可在任何必要时刻修改价格。

State还是Strategy？

为了引入State模式，我使用了三个重构手法。首先运用Replace Type Code with State/Strategy。将类型相关的行为移到State模式内。然后运用Move Method将switch语句移到Price类。最后运用Replace Conditional with Polymorphism去掉switch语句。

首先我要使用Replace Type Code with State/Strategy。第一步是针对类型代码使用Self Encapsulate Field，确保任何时候都通过取值函数和设值函数来访问类型代码。

1.5 结语