重构，如何从代码工人变成考究工匠

《重构》这本书常傍身，最近因为面试又大致的浏览了一遍，理一理自己的理解。

这里主要对“过长函数（long methods）”进行优化的几点记录。

1、Extract Method提炼函数

2、Inline Method内联函数

3、Replace Temp With Query以查询替代临时变量

4、Split Temporay Variable分解临时变量

5、Replace Method With Method Object以方法对象替换方法

6、Remove Assignments to Parameters去除参数赋值

7、Substitute Algorithm 替换算法

 

就以上集中重构方法谈谈自己的理解吧。

1（提炼函数）和2（内联函数）其实是对立的，看过本书的朋友应该都清楚，里面的重构方法有很多是对立的，其实我觉得总言之是为了增加程序的可读性和聚合性来看待1（提炼函数）和2（内联函数）选择。

 

1（提炼函数）首先是对程序结构上，目的是减少主程序逻辑理解复杂度，一个好的函数名称可以替代一段注释（所以E文是非常重要的），函数的取名非常重要，在这段程序的结构上是增加了程序的可读性。一段逻辑在一段长函数中并不一定因为某些和其他函数有共性的逻辑才应该提炼，有逻辑独立，并且可以通过函数名称明确的表达出来这段的代码的意思就应该是可以抽离的，这种抽离并不是因为程序的聚合，而是为了增加程序的可读性。

2（内联函数）在考虑到某个函数在本身非常简单，函数内部代码本身是足以表达出意思，并且当前和未来都不太可能有共性函数出现的情况下就可以考虑，内联到使用函数的内部。

3（以查询替代临时变量）其实从全书能看到，临时变量其实并不受Martin Fowler待见，作者可能认为临时变量是重构的大敌之一。几点原因吧，一个其本身没什么复用性（这个不聊），

主要是第二点通过这个重构方法可以让更多的重构方法更易被使用，谈个简单的例子：

首先如果你对某段含有临时变量的程序段使用1（提炼函数）提炼出来一个A()这么个函数，原先你有个临时变量B，那么你有两个选择，一种就是在调用A()的时候把B当成参数传递A，就是A（B），一种选择是在A函数种申明这个变量B。显然这两种方法都是有问题的，第一种增加了A函数的使用复杂度，多增加了一个参数，第二种如果A这个函数的容器函数还有其他地方使用到这个临时变量或者其他提炼函数也用到了这个B，那么你代码的聚合就差了。所以还不出申明个全局变量，这样就解决了问题，但是全局变量的是有问题的，我们申明这个临时变量的目的就是为了用的时候进行计算赋值，而全局变量是在容器对象创建的时候初始赋值，如果用的时候再对全局变量赋值，那么也没多大意义，所以直接引入查询（其实就是函数），这样在提炼函数出来的这个函数或者原函数本身调用这个通过临时变量替换出来的函数时进行返回值运算值运算无疑是最好的方法。

 

4（分解临时变量）其实这个应该是在3前面，也是程序可读性的问题，临时变量不要重复赋值，不要词不达意，不要含含糊糊，要明确，写代码不能以编译器能通过为准毕竟是给人看的，不要出现temp这样的临时变量也更不能重复使用，更不能temp1和temp2的用。（以前有个孩子给我介绍grails的优点的时候跟我说def声明的变量是弱类型，他用def申明了一个变量结果整个代码块使用的临时变量全部用那一个变量，当时我也只能无语，如果语言的开发者知道他是这么干的话估计能吐血）。

 

5（以方法对象替换方法） 其实这个很好理解，有些对象中的函数其实在很多地方都用到了，抽离父类不太合适，这些使用到这个函数的某些共性而已，没必要增加继承体系，再说java本身的单继承也不能乱用继承来达到目的，那么通过方法对象，抽离出一些方法，被这些调用者所使用。说的有点像策略模式，不过更轻量。当然模式最终也就是这么抽离出来的，如果这些被抽离的方法组织成的方法对象有深化的可能，在使用控制翻转让方法对象有继承体系，也未尝不是出来模式。

 

6、（去除参数赋值）还是可读性，不要对你的参数进行赋值，因为这样会增加程序阅读的复杂度而且容易造成错误。

 

7、（替换算法）这块主要是程序开发者的功力了，如何使用好的算法来增加程序的可读性和速度优化，这块其实也很重要，不要没有上面几个重构方法来的实在。

 

总而言之严谨的编码风格和代码细节是非常重要的。一定要成为考究的程序员而不仅仅是拷贝的代码工人。