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

    继续我的重构之旅，Come On！

    1.经过了之前的一次搬运Switch..Case语句，原来的statement函数体积掉了一小半，接下来要对后续的代码下手了。接着马上就看到了一句:

...
//add frequent renter points
frequentRenterPoints++;
...

    这句代码往这里一放，不是自己写的人肯定不知道是什么意思，而且这句是一个很烂的代码，应该用一句更加“程序化”的代码来解释这句话，而且这句中还包含了一个局部变量，对于这种眼中钉必须马上剔除。继而有了下面的代码：

Class Customer
...
frequentRenterPoint+=each.getFrequentRenterPoints();
...

Class Rental
...
int getFrequentRenterPoints()
{
   if(...)
     {return 2;}
   else
     {return 1;}
}
...

     这一步事实上是两个操作的集合，第一步先将原来的不明显的代码写成“程序化”的一句，这其中就需要获取到一个值，这个取值函数想了想，发现这个函数取的数据是属于另外一个类的，因此再次将这个函数搬迁至另一个类中。

     还是之前的办法，分离函数，考虑函数行为应该属于哪个类，将函数搬迁，并且再原代码中添加相应的对象函数来取代原代码。这样做的好处刚开始的时候我并没有感觉出来，但是做完这一次重构，再看程序的UML视图，在书上P24，震惊啊！程序的架构竟然改变了，相比之之前的混乱，很明显架构正在向着好的方向迈进，这难道是架构在进化么？！难道这就是重构的魔力？！

     2.接着扫一眼接下来的代码，有一种东西在作者眼中是难以忍受的，那就是局部变量，一定要把局部变量变成相应的函数获取。现在还不明显的知道为什么，但是考虑到作者用了一些给力的测试工具，这种测试工具能够测试出来多少个对象创建以及多少个函数执行，但是貌似是检测不到局部变量的操作，这就给作者后期优化程序制造了障碍，这可能也是作者为什么说“局部变量使程序变得不可控”的原因吧。

     3.再次修改了两个局部变量之后，和之前一样，分离函数，将函数放到它应该的位置，又一次发现架构进化了，在P30，相比之前，又一次显示出了更强的条理性。对局部变量的修改很大程度上可以优化架构，因为他提炼了函数，并放到了合适的位置；而且在原代码中增加了调用，使得各个类之间更加清晰。

     4.看到不同的价格以及折扣，即使不通过上面的重构，也可以想到策略模式(Strategy)的设计，但是作者使用的是状态模式(State)的设计。作者说使用哪一种模式取决于对影片的理解，也是对业务或者是对架构的理解。如果认为三种电影是三种不同的收费模式主要的，那就是用Strategy；如果是认为是影片的三种状态(老电影，新电影，儿童电影)是主要的，是状态决定了收费，那就用State。看到这里有一点纠结了，原来对业务的理解直接影响着使用哪种设计模式，不懂业务真是啥都不行。

     5.接下来作者对那个Switch..Case分化出去的函数做了一个State模式，这其中使用到了一个Price状态层，这是State模式的固有的东西。最终看到的是P51页的UML视图，条理清晰，一目了然。不得不说，作者将这个小程序重构出了艺术，绝对的艺术层面了。

      第一章小结：作者通过一个影片出租店的例子，从开始的一片狼藉(即使代码可以运行)到重构完成后的堪称艺术的代码，实在是将重构手法体现到了极致，而且作者并没有刻意的去站在一个非常高的角度对代码进行点评，而是亦步亦趋的按照重构的基本思路一步一步进行了重构，每一次的重构都感觉是顺其自然，其中使用的重构手法也没有特别难的，是一些基本的Extract Method，Replace Temp with Query等等，最后的设计模式也是顺其自然的添加，整个过程一气呵成，相信看完这本书能有作者这么清晰的思路吧。 

      未完待续。。

转载于:https://www.cnblogs.com/yangqipeng89422/archive/2013/01/17/2863603.html