漫谈重构

未分类

最近在读改善既有代码的设计，有一些笔记和心得，固有此记。

Duplicated Code

如果在一个以上的地方看到相同的程序结构，那么你就应该设法将其合而为一。在平常开发中经常会遇到这种情景。

重复代码在需要修改某逻辑时会造成一些麻烦，我们不得不把所有应用此逻辑代码全部进行修改。如果是两个不相关的类中出现重复代码结构，应考虑把重复部分进行提取封入新的方法（Extract Method），然后两个地方都调用此方法，需要考虑的地方就是这个新提取出来的方法应该放在什么地方。

还有一种情况就是两个兄弟子类中含有相同的代码逻辑，此时应进行 Extract Method ，然后把这个新方法丢到超类中。如果代码之前只是相似，也并不是完全相同，这时有洁癖的人就会感到如鲠在喉但是又不能直接拔掉，那么就可以考虑稍稍费些功夫将相似部分和差一部分分开，构成一个单独的函数。

Long Method

如标题所说：长函数，相信开发人员都有体会，程序越长越难理解。

此书中的看法是，你应该更加积极的去分解函数。每当感觉需要以注释来说明部分逻辑的时候，就需要把要说明的东西单独封入一个独立的函数中，并以其用途起一个形象易理解的名字。（如果你能给函数起一个好名字，使阅读代码的人可以通过名字就了解函数的作用，那就最好了）。

在提炼函数的过程中，经常遇到的一个问题是当原函数内有大量的参数和临时变量，这些东西会对提取函数的过程形成不小的阻碍，如果就直接把许多的参数和临时变量当作参数在函数之间传递，在很多时候会导致可读性几乎没有提高。此时就需要考虑一些辅助手法来处理这些临时变量和参数了，此部分后续在详细说明。

原文中提到‘就算只有一行代码，如果它需要以注释来说明，那也值得将它提炼到独立函数去’，这句话我并不完全认同，个人认为应该视情况而定，因为过多的函数调用也会增加上下文切换的开销，虽然有听说过现在OO语言已经几乎完全免除了进程内的函数调用开销，不过我还是在内心中对频繁的函数间切换抱有抵触。

Long Parameter List

当有的函数需要你不得不传递一长串的参数进去时，会不会觉得无比苦恼既难写又难看更难理解，太多参数也会造成前后不一致不宜使用，而且当你需要更多数据时，就不得不修改它。。。
利用对象这一概念可以很好的处理这种情况，如果你手头上没有所需的数据，总是可以叫另一个对象给你。利用对象，就不必把所有东西以参数传递给函数，而是传递给它足够的让函数能从中获取所需数据的对象就行了。所以，面向对象程序中的函数，其参数列通常比传统程序要短得多。