重构——代码的坏味道 (1)

1. Duplicated Code(重复的代码)

臭味行列中首当其冲的就是Duplicated Code。如果你在一个以上的地点看到相同的程序结构,那么当可肯定:设法将它们合而为一,程序会变得更好。

最单纯的Duplicated Code就是[同一个class内的两个函数含有相同表达式(expression)]。这时候你需要做的就是采用Extract Method提炼出重复的代码,然后让这两个地点都调用被提炼出来的那一段代码。

另一种常见情况就是[两个互为兄弟(sibling)subclasses内含有相同表达式]。要避免这种情况,只需要对两个classes都使用Extract Method,然后再对被提炼出的代码使用Pull Up Method,将它推入superclass内。如果代码之间只是类似,并非完全相同,那么就得运用Extract Method将相似部分和差异部分割开,构成单独一个函数。然后你可能发现或许可以运用Form Template Method获得一个Template Method设计模式。如果有些函数以不同的算法做相同的事,你可以择定其中较清晰的一个,并使用Substitute Algorithm将其它函数的算法替换掉。

如果两个毫不相关的classes内出现Duplicated Code,你应该考虑对其中一个使用Extract Class,将重复代码提炼到一个独立class中,然后在另一个class内使用这个新class。但是,重复代码所在的函数也可能的确只应该属于某个class,另一个class只能调用它,抑或这个函数可能属于第三个class,而另两个classes应该引用这第三个class。你必须决定这个函数放在哪儿最合适,并确保它被安置后就不会再在其它任何地方出现。

2. Long Method(过长函数)

拥有[短函数](short methods)的对象会活得比较好、比较长。不熟悉面向对象技术的人,常常觉得对象程序中只有无穷无尽的delegation(委托),根本没有进行任何计算。和此类程序共同生活数年之后,你才会知道,这些小小函数有多大价值。[间接层]所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型函数支持的。

很久以前程序员就已认识到:程序愈长愈难理解。早期的编程语言中,[子程序调用动作]需要额外开销,这使得做你们不太乐意使用small method,现代OO语言几乎已经完全免除了进程内的[函数调用动作额外开销]。不过代码阅读者还是得多费力气,因为他必须经常转换上下文去看看子程序做了什么。某些开发环境允许用户同时看到两个函数,这可以帮助你省去部分麻烦,但是让small method容易理解的真正关键在于一个好名字。如果你能给函数起个好名字,读者就可以通过名字了解函数的作用,根本不必去看其中写了些什么。

最终的效果是:你应该更积极进取地分解函数。我们遵循这样一条原则:每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立的函数中,并以其用途(而非实现手法)命名。我们可以对一组或甚至短短一行代码做这件事。哪怕替换后的函数调用动作比函数自身还长,只要函数名称能够解释其用途,我们也该毫不犹豫地那么做。关键不在于函数的长度,而在于函数[做什么][如何做]之间的语义距离。

百分之九十九的场合里,要把函数变小,只需使用Extract Method。找到函数中适合集在一起的部分,将它们提炼出来形成一个新函数。

如果函数内有大量的参数和临时变量,它们会对你的函数提炼形成阻碍。如果你尝试运用Extract Method,最终就会把许多这些参数和临时变量当作参数,传递给被提炼出来的新函数,导致可读性几乎没有任何提升。啊是的,你可以经常运用Replace Temp with Query则可以将过长的参数列变得更简洁一些。

如果你已经这么做,仍然有太多临时变量和参数,那就应该拿出我们的杀手锏:Replace Method with Method Object

如何确定该提炼哪一段代码呢?一个很好的技巧是:寻找注释。它们通常是指出[代码用途和实现手法间的语义距离]的信号。如果代码前言有一行注释,就是在提醒你:可以将这段代码替换成一个函数,而且可以在注释的基础上给这个函数命名。就算只有一行代码,如果它需要以注释来说明,那也值得将它提炼到独立的函数去。

条件式和循环常常也是提炼的信号。你可以使用Decompose Conditional处理条件式。至于循环,你应该将循环和其内的代码提炼到一例独立函数中。

3. Large Class(过大类)

如果想利用单一class做太多事情,其内往往就会出现太多instance变量。一旦如此,Duplicated Code也就接踵而至了。

你可以运用Extract Class将数个变量一直提炼到新class内。提炼时应该选择class内彼此相关的变量,将它们放在一直。例如”depositAmount””depositCurrency”可能应该隶属同一个class。通常如果class内的数个变量有着相同的前缀或字尾,这就意味有机会把它们提炼到某个组件内。如果这个组件适合作为一个subclass,你会发现Extract Subclass往往比较简单。

有时候class并非在所有时刻都使用所有instance变量。果真如此,你或许可以多次使用Extract ClassExtract Subclass

[太多instance变量]一样,class内如果有太多代码,也是[]代码重复、混乱、死亡]的绝佳滋生地点。最简单的解决方案是把赘余的东西消弭于class内部。如果有五个[百行函数],它们之中很多代码都相同,那么或许你可以把它们变成五个[十行函数]和十个提炼出来的[双行函数]。

[拥有太多instance变量]一样,一个class如果拥有太多代码,往往也适合使用Extract ClassExtract Subclass。这里有个有用技巧:先确定客户端如何使用它们,然后运用Extract Interface为每一种使用一个接口。这或许可以帮助你看清楚如何分解这个class

如果你的Large Class是个GUI class,你可能需要把数据和行为移到一个独立的领域对象去。你可能需要两边各保留一些重复数据,并令这些数据同步。Duplicate Observed Data告诉你该怎么做。这种情况下,特别是如果你使用旧式AWT组件,你可以采用这种方式去掉GUI class并代以Swing组件。

4. Long Parameter List(过长参数列)

刚开始学习编程的时候,老师教我们:把函数所需的所有东西都以参数传递进去。这可以理解,因为除此之外就只能选择全局数据,而全局数据是邪恶的东西。对象技术改变了这一情况,因为如果你手上没有你所需要的东西,总可以叫另一个对象给你。因此,有了对象,你就不必把函数需要的所有东西都以参数传递给它了,你只需给它足够的东西、让函数能从中获得自己需要的所有东西就行了。函数需要的东西多半可以在函数的宿主类(host class)中找到。面向对象程序中的函数,其参数列通常比在传统程序中短得多。

这是好现象,因为太长的参数列难以理解,太多参数会造成前后不一致、不易使用,而且一旦你需要更多数据,就不得不修改它。如果将对象传递给函数,大多数修改都将没有必要,因为你很可能只需(在函数内)增加一两条请求,就能得到更多数据。

如果[向既有对象发出一条请求]就可以取得原本位于参数列上的一份数据,那么你应该激活重构准则Replace Parameter with Method。上述的既有对象可能是函数所属class内的一个值域,也可能是另一个参数。你还可以运用Preserve Whole Object将来自同一对象的一堆数据收集起来,并以该对象替换它们。如果某些数据缺乏合理的对象归属,可使用Introduce Parameter Object为它们制造出一个[参数对象]

此间存在一个重要的例外。有时候你明显不希望造成[被调用之对象][较大对象]间的某种依存关系。这时候将数据从对象中拆解出来单独作为参数,也很合情合理。但是请注意其所引发的代价。如果参数列太长或变化太频繁,你就需要重新考虑自己的依存结构了。

5. Divergent Change(发散式变化)

我们希望软件能够更容易被修改——毕竟软件再怎么说本来就该是[]的。一旦需要修改,我们希望能够跌到系统的某一点,只在该处做修改。如果不能做到这点,你就嗅出两种紧密相关的刺鼻味道中的一种了。

如果某个class经常因为不同的原因在不同的方向上发生变化,Divergent Change就出现了。当你看着一个class说:“呃,如果新加入一个数据库,我必须修改这三个函数;如果新出现一种金融工具,我必须修改这四个函数”,那么此时也许将这个对象分成两个会更好,这么一来每个对象就可以只因一种变化而需要修改。当然,往往只有在加入新数据库或新金融工具后,你才能发现这一点。针对某一外界变化的所有相应修改,都只应该发生在单一class中,而这个新class内的所有内容都应该反应该外界变化。为此,你应该找出因着某特定原因而造成的所有变化,然后运用Extract Class将它们提炼到另一个class中。

6. Shotgun Surgery(霰弹式修改)

Shotgun Surgery类似Divergent Change,但恰恰相反。如果每遇到某种变化,你都必须在许多不同的class内做出许多小修改以响应之,你所面临的坏味道就是Shotgun Surgery。如果需要修改的代码散布四处,你不但很难找到它们,也很容易忘记某个重要的修改。

这种情况下你应该使用Move MethodMove Field把所有需要修改的代码放进同一个class。如果眼下没有合适的class可以安置这些代码,就创造一个。通常你可以运用Inline Class把一系列相关行为放进同一个class。这可能会造成少量Divergent Change,但你可以轻易处理它。

Divergent Change是指[一个class受多种变化的影响]Shotgun Surgery则是指[一种变化引发多个classes相应修改]。这两种情况下你都会希望整理代码,取得[外界变化][待改类]呈现一对一关系的理想境地。

7. Feature Envy(依恋情结)

对象技术的全部要点在于:这是一种[将数据和加诸其上的操作行为包装在一起]的技术。有一种经典气味是:函数对某个class的兴趣高过对自己所处之host class的兴趣。这种孺慕之情最通常的焦点便是数据。无数次经验里,我们看到某个函数为了计算某值,从另一个对象那儿调用几乎半打的取值函数。疗法显而易见:把这个函数移到另一个地点。你应该使用Move Method把它移到它该去的地方。有时候函数中只有一部分受这种依恋之苦,这时候你应该使用Extract Method把这一部分提炼到独立函数中,再使用Move Method带它去它的梦中家园。

当然,并非所有情况都这么简单。一个函数往往会用上数个classes特性,那么它究竟该被置于何处呢?我们的原则是:判断哪个class拥有最多[被此函数使用]的数据,然后就把这个函数和那些数据摆在一起。如果先以Extract Method将这个函数分解为整个较小函数并分别置放于不同地点,上述步骤也就比较容易完成了。

有数个复杂精巧的模式破坏了这个规则。说起这个话题,[四巨头]的StreategyVisitor立刻跳入我的脑海,Kent BeckSelf Delegation也丰此列。使用这些模式是为了对抗坏味道Divergent Change。最根本的原则是:将总是一起变化的东西放在一块儿。[数据]和[引用这些数据]的行为总是一起变化的,但也有例外。如果例外出现,我们就搬移那些行为,保持[变化只在一起发生]StrategyVisitor使你得以轻松修改函数行为,因为它们将少量需要被覆写的行为隔离开来——当然也付出了[多一层间接性]的代价。

8. Data Clumps(数据泥团)

数据项就像小孩子:喜欢成群结队地待在一块儿。你常常可以在很多地方看到相同的三或四笔数据项:两个classes内的相同值域、许多函数签名式中的相同参数。这些[总是绑在一起出现的数据]真应该放进属于它们自己的对象中。首先请找出这些数据的值域形式出现点,运用Extract Class将它们提炼到一个独立对象中。然后将注意力转移到函数签名式上头,运用Introduce Parameter ObjectPreserve Whole Object为它减肥。这么做的直接好处是可以将很多参数列缩短,简化函数调用动作。是的,不必因为Data Clumps只用上新对象的一部分值域而在意,只要你以新对象取代两个(或更多)值域,你就值回票价了。

一个好的评断办法是:删掉众多数据中的一笔。其它数据有没有因而失去意义?如果它们不再有问询,这就是个明确信号:你应该为它们产生一个新对象。

缩短值域个数和参数个数,当然可以支队一些坏味道,但更重要的是:一旦拥有新对象,你就有机会让程序散发出一种芳香。得到新对象后,你就可以着手寻找Feature Envy,这可以帮你指出[可移到新class]中的种种程序行为。不必太久,所有classes都将在它们的小小社会中充分发挥自己的生产力。

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭