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

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

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

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

4、查看局部变量在switch语句内是否被修改，没有被修改的，可以考虑当做参数传入

被修改的可以考虑，作为独立函数的返回值返回。返回的一个变量，可以改名为result，看着就知道是什么意思。传入的rental，可以改为aRental，表明是一个。

注意返回值类型。

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

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

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

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

8、去除临时变量。临时变量可能是个问题，它们只在自己所属的函数中有效，它们会助长冗长而复杂的函数。在Customer类中新建一个方法getTotalCharge（），重新编写计算过程，然后用这个方法取代totalAmount这个局部变量。临时变量frequentRenterPoints也做同样的处理。我们需要把循环复制到这两个方法中

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

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

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

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