重构_改善既有的代码设计（一）

一、代码块愈小，代码的功能就愈容易管理

二、将switch语句，提炼到独立的函数中

三、寻找switch语句中的局部变量

四、查看局部变量在switch语句内是否被修改，没有被修改的，能够考虑当作参数传入

被修改的能够考虑，做为独立函数的返回值返回。返回的一个变量，能够更名为result，看着就知道是什么意思。传入的rental，能够改成aRental，代表是一个。

注意返回值类型。

五、发现独立函数使用了来了Rental类的信息，却没有使用来自Customer类的信息，

可能函数放错地方了，将函数移到Rental中，并修改方法名为getCharge，由于这是一个计算费用的方法，方法名要能表示功能。

六、发现原来statement方法中的thisAmount变量，接受each.getCharge（）的执行结果以后，就再也不有任何改变，因此能够直接用each.getCharge（）代替。尽可能去除这一类临时变量。临时变量每每引起问题，它们会致使大量参数被传来传去，而其实彻底没有这种必要。你很容易跟丢它们，尤为在长长的函数之中更是如此。固然这么作也需付出性能上的代价，好比本例的费用就被计算了两次。但这很容易在Rental类中被优化。。。并且若是代码有合理的组织和管理，优化就会有很好的效果。

七、将statement方法中的“常客积分计算”部分，抽出来，看着应该是放在Rental类中。临时变量frequentRenterPoints，在它被使用以前，先有初始值，可是提炼出来的函数并无读取该值，因此咱们不须要将它当作参数传进去，只需把新函数的返回值累加上去就行。

八、去除临时变量。临时变量多是个问题，它们只在本身所属的函数中有效，它们会滋长冗长而复杂的函数。在Customer类中新建一个方法getTotalCharge（），从新编写计算过程，而后用这个方法取代totalAmount这个局部变量。临时变量frequentRenterPoints也作一样的处理。咱们须要把循环复制到这两个方法中

九、这时候，用户准备更改影片分类规则，与之相对应的费用计算方式和常客积分计划还有待决定，如今还不宜对程序作修改。咱们必须进入费用计算和常客积分计算中，把因条件而异的代码替换掉（这里指的是switch语句中的case子句）

十、运用多态取代与价格相关的条件逻辑。最好不要在另外一个对象的属性基础上运用switch语句。若是不得不使用，也应该在对象本身的数据上使用，而不是在别人的数据上使用。如本例，switch(getMovie().getPriceCode())...暗示getCharge()应该移到Movie类里去，须要把租期长度做为参数传进去。租赁长度来自Rental对象。计算费用时须要两项数据：租期长度和影片类型。为何选择将租期长度传给Movie对象，而不是将影片类型传给Rental对象？系统可能发生的变化时加入新影片类型，若是影片类型有所变化，尽可能控制它形成的影响（保持不变），因此选择在Movie对象内计算费用。用一样的手法处理常客积分计算。

十一、一部影片能够在生命周期内修改本身的分类，一个对象却不能在生命周期内修改本身所属的类（这句话有点抽象啊，不是很理解）。下面引入State模式与Strategy模式，以前只据说过Strategy模式，补一下State模式，并了解到这两个设计模式很是类似，只是State多了状态的改变（不知道说得对不对）。

接下来是一堆的重构。第一个例子很是精美，对重构感兴趣的，均可以去看一看