读书笔记之《重构-改善既有代码的设计》第一章

重构是一本很优秀的书，记此笔记，我尽量想将自己的理解过程表达出来，因此有些地方会感觉解释罗嗦。另外觉得读之前，尽可能熟悉UML图，对理解会有帮助。
第一个案例，是一个影片出租店使用的小程序。这个案例中的代码，光是细看前，就觉得statement()函数太长，分析了一下这段代码的作用，所有功能都直接写在了statement()中，功能上来讲，这个程序并没有多大问题，仅仅满足这个店的使用需求就行了。但是当以后代码中某些需求或者功能需要发生改变的时候，就需要修改代码，可以直接复制一份，然后从中修改，直接定位到statement()这个函数中，然后寻找关于计费方式的部分，修改之，这样的代码量下，可以很容易做到，但是假设我们把这个函数功能增加更多，看起来更长，再去找到其中的某个功能就要相对费劲一些了。假如原来的程序和复制后修改了部分功能的程序都在使用，过了一段时间，我们需要修改某两个小程序共有的功能，

比如计费方式，那就需要同时修改两个相同的代码两次。
这样的小程序很容易理解，通过这个例子，作者也很自然地引入了重构。讲明白为什么要重构，就是当我们的代码中有这样的设计思路的时候，就是后面提到的代码的坏味道，就需要重构。当然这是我对目前读到的部分的理解，为什么要重构，肯定不够全面。
以下部分总结一下自己的理解。
重构的第一步是需要有一套可靠的测试机制，假设一些顾客，租赁影片，然后计算比对。说得直白一些，就是在每一次重构之后，都需要对功能进行测试，是否引入了bug，需要造一些合理的数据来让程序运行比对。如果重构后不测试，后面再去运行，修改的地方多很容易引入bug。
假如我们出现上面出现的情况，需要对功能做出修改，重构怎么入手呢。书中告诉我们，首先需要找出代码的逻辑泥团，运用Extract Method(110)，我翻到110页Extract Method(提炼函数)，有一段代码可以被组织在一起并独立出来，并且让函数名称解释改函数的用途。逻辑泥团我理解得不是很好，暂且我觉得可以把函数中的功能都抽取出来放入独立的函数中，只是重构的时候，小步推进，先对哪个部分动刀需要判断，不同的功能的重构顺序可能需要根据谁更倾向于“逻辑泥团”来排序。书中将第一步重构前后的statement()函数进行对比，很明显地看到switch部分被独立到了amountFor函数中，需要的时候就调用。并且修改计费的时候，只需要修改amountFor函数就行了，方便了管理。总结一下，就是代码块越小，对代码的管理就越轻松，比如我们之前找计费功能需要在statement中找，现在只需要立即定位到amountFor中就行了，而且单一的功能被调用的时候也更方便。修改变量名称也是很值得做的事情，好代码不是机器能理解就行的，好的名称应该清楚表达出自己的功能。
　　对函数的修改用到了Move Method（函数搬移），书中提到，绝大多数情况下，函数应该放在它所使用的数据的所属对象内。程序中有个函数语气所驻类之外的另一个类进行更多交流，即调用后者或被后者调用，amountFor()函数在Customer类中，却使用了Rental类中的数据，属于此类现象。
　　书中还介绍了使用继承，使用多态来取代switch语句，但是在此例中不能这么做，原因是影片可以在生命周期内修改自己的分类，一个对象却不能在生命周期内修改自己所属的类。对该部分的理解还不够深入，因此不能很好地解释这一部分。书中提供了一个解决方法，用State模式（状态模式），通过调研，对State模式了解了一些，状态模式允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类，这里书中使用了三个重构手法。我只是大略了解哪些手法，详细研究后后面的笔记中将自己所理解尽可能表述清楚。