章节三 代码的坏味道

*这一部分的内容最好在CHM文件中去阅读

Duplicated Code （重复代码）

同一个class内的两个函数含有相同表达式（expression）

采用Extract Method提炼出重复的代码，然后让这两个地点都调用被提炼出来的那一段代码。

两个互为兄弟〔sibling）的subclasses内含相同表达式

对两个classes都使用Extract Method，然后再对被提炼出来的代码使用 Pull Up Field，将它推入superclass内。如果代码之 间只是类似，并非完全相同，那么就得运用Extract Method将相似部分和差异部分割开，构成单独一个函数。然后你可能发现或许可以运用Form Template Method获得一个Template Method设计模式。如果有些函数以不同的算法做相同的事，你可以择定其中较清晰的一个，并使用Substitute Algorithm将其他函数的算法替换掉。

两个毫不相关的classes内出现Duplicated Code

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

Long Method（过长函数）

让small method容易理解的真正关键在于一个好名字。如果你能给函数起个好名字，读者就可以通过名字了解函数的作用，根本不必去看其中写了些什么。

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

Large Class（过大类）

可以运用Extract Class将数个变量一起提炼至新class内。提炼时应该选择class内彼此相关的变量，将它们放在一起。

Long Parameter List（过长参数列）

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

Divergent Change（发散式变化）

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

Shotgun Surgery（散弹式修改）

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

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

Feature Envy（依恋情结）

函数对某个class的兴趣高过对自己所处之host class的兴趣。这种孺慕之情最通常的焦点便是数据。无数次经验里，我们看到某个函数 为了计算某值，从另一个对象那儿调用几乎半打的取值函数（getting method）。疗法显而易见：把这个函数移至另一个地点。你应该使用Move Method 把它 移到它该去的地方。有时候函数中只有一部分受这种依恋之苦，这时候你应该使用 Extract Method 把这一部分提炼到独立函数中，再使用Move Method 带它去它的梦中家园。

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

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

Data Clumps（数据泥团）

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

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

Primitive Obsession（基本型别偏执）

大多数编程环境都有两种数据：结构型别（record types）允许你将数据组织成有意义的形式；基本型别（Primitive type）则是构成结构型别的积木块。结构总是会带 来一定的额外开销。

对象的一个极具价值的东西是：它们模糊（甚至打破）了横亘于基本数据和体积较大的classes之间的界限。你可以轻松编写出一些与语言内置（基本〕型别无异的小型classes。例如Java就以基本型别表示数值，而以class表示字符串和日期。

对象技术的新手通常不愿意在小任务上运用小对象——像是结合数值和币别的 money classes 、含一个起始值和一个结束值的range classes、电话号码或邮政编码（ZIP） 等等的特殊strings。你可以运用Replace Data Value with Object 将原本单独存在的数据值替换为对象，从而走出传统的洞窟，进入炙手可热的对象世界。如果欲替换之数据值是 type code（型别码），而它并不影响行为，你可以运用 Replace Type Code with Class 将它换掉。如果你有相依于此 type code的条件式，可运用 Replace Type Code with Subclasses 或 Replace Type Code with State/Strategy 加以处理。

如果你有一组应该总是被放在一起的值域（fields），可运用Extract Class。 如果你在参数列中看到基本型数据，不妨试试Introduce Parameter Object。 如果你发现自己正从array中挑选数据，可运用Replace Array with Object。

Switch Statements（switch惊悚现身）

面向对象程序的一个最明显特征就是：少用switch (或case）语句。从本质上说， switch语句的问题在于重复（duplication）。你常会发现同样的switch语句散布 于不同地点。如果要为它添加一个新的子句，你必须找到所有switch语句 并修改它们。面向对象中的多态（polymorphism ）概念可为此带来优雅的解决办法。

大多数时候，一看到switch语句你就应该考虑以「多态」来替换它。问题是态 该出现在哪儿？switch语句常常根据 type code（型别码）进行选择，你要的是「与 该 type code相关的函数或class」。所以你应该使用Extract Method 将switch语句提炼到一个独立函数中，再以Move Method 将它搬移到需要多态性的那个class里头。此时你必须决定是否使用 Replace Type Code with Subclasses 或 Replace Type Code with State/Strategy。一旦这样完成继承结构之后， 你就可以运用Replace Conditional with Polymorphism了。

如果你只是在单一函数中有些选择事例，而你并不想改动它们，那么「多态」就有 点杀鸡用牛刀了。这种情况下Replace Parameter with Explicit Methods是个不错的选择。如果你的选择条件之一是null，可以试试Introduce Null Object。

Parallel Inheritance Hierarchies（平行继承体系）

Parallel Inheritance Hierarchies其实是shotgun surgery的特殊情况。在这种情况下，每当你为某个class增加一个subclass，必须也为另一个class相应增加一个subclass。如果你发现某个继承体系的名称前缀和另一个继承体系的名称前缀完全相同，便是闻到了这种坏味道。

消除这种重复性的一般策略是：让一个继承体系的实体（instance）指涉（参考、引用、refer to）另一个继承体系的实体(instances)。如果再接再厉运用Move Method 和 Move Field，就可以将指涉端（ referring class ）的继承体系消弭于无形。

Lazy Class（冗赘类）

你所创建的每一个class，都得有人去理解它、维护它，这些工作都是要花钱的。==如 果一个class的所得不值其身价，它就应该消失。== 项目中经常会出现这样的情况： 某个class原本对得起自己的身价，但重构使它身形缩水，不再做那么多工作；或开发者事前规划了某些变化，并添加一个class来应付这些变化，但变化实际上没 有发生。不论上述哪一种原因，请让这个class庄严赴义吧。如果某些subclass没有做满足够工作，试试 Collapse Hierarchy。对于几乎没用的组件，你应该以Inline Class对付它们。

Speculative Generality（夸夸其谈未来性）

当有人说『噢，我想我们总有一天需要做这事』并因而企图以各式各样的挂勾（hooks）和特殊情况来处理一 些非必要的事情，这种坏味道就出现了。那么做的结果往往造成系统更难理解和维护。如果所有装置都会被用到，那就值得那么做；如果用不到，就不值得。 用不上的装置只会挡你的路，所以，把它搬开吧。

如果你的某个abstract class其实没有太大作用，请运用Collapse Hierarchy。非必要之delegation （委托）可运用Inline Class 除掉。如果函数的某些参数未被用上，可对它实施 Remove Parameter。如果函数名称带有多余的抽象意味，应该对它实施Rename Method 让它现实一些。

如果函数或class的惟一用户是test cases （测试用例），这就飘出了坏味道Speculative Generality。如果你发现这样的函数或class，请把它们连同其test cases都删掉。但如果它们的用途是帮助test cases检测正当功能，当然必须刀下留人。

Temporary Field（令人迷惑的暂时值域）

有时你会看到这样的对象：其内某个instance变量仅为某种特定情势而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初其设置目的，会让你发疯。

请使用 Extract Class 给这个可怜的孤儿创造一个家，然后把所有和这个变 量相关的代码都放进这个新家。也许你还可以使用 Introduce Null Object 在「变量不合法』的情况下创建一个Null对象，从而避免写出『条件式代码」。

如果class中有一个复杂算法，需要好几个变量，往往就可能导致坏味道Temporary Field的出现。由于实现者不希望传递一长串参数（想想为什么），所以他把这些 参数都放进值域（field）中。但是这些值域只在使用该算法时才有效，其他情况下只会让人迷惑。这时候你可以利用 Extract Class 把这些变量和其相关函数提炼到一个独立class中。提炼后的新对象将是一个method object[Beck]（译注：其存在只是为了提供调用函数的途径，class本身并无抽象意味）。

Message Chains（过度耦合的消息链）

如果你看到用户向一个对象索求（request）另一个对象，然后再向后者索求另一个对象，然后再索求另一个对象……这就是Message Chains。实际代码中你看到的可 能是一长串getThis()或一长串临时变量。采取这种方式，意味客户将与查找过程中的航行结构（structure of the navigation）紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不做出相应修改。

这时候你应该使用Hide Delegate。你可以在Message Chains的不同位置进行这种重构手法。理论上你可以重构Message Chains上的任何一个对象，但这么做往往会把所有中介对象（intermediate object ）都变成Middle Man。通常更好的选择是：==先观察Message Chains最终得到的对象是用来干什么的，看看能否以 Extract Method 把使用该对象的代码提炼到一个独立函数中，再运用Move Method 把这个函数推入Message Chains。== 如果这条链上的某个对象有多位客户打算航行此航线的剩余部分，就加一个函数来做这件事。

有些人把任何函数链（method chain。译注：就是Message Chains；面向对象领域中所谓「发送消息」就是「调用函数」）都视为坏东西，我们不这样想。呵呵，我们的冷静镇定是出了名的，起码在这件事情上是这样。

Middle Man（中间转手人）

对象的基本特征之一就是封装（encapsulation）——对外部世界隐藏其内部细节。封装往往伴随delegation （委托）。

但是人们可能过度运用delegation。你也许会看到某个class接口有一半的函数都委托给其他class，这样就是过度运用。这时你应该使用Remove Middle Man，直接和实责对象打交道。如果这样「不干实事」的函数只有少数几个，可以运用 Inline Method 把它们” Inlining”，放进调用端。如果这些Middle Man还有其他行 为，你可以运用 Replace Delegation with Inheritance 把它变成实责对象的subclass，这样你既可以扩展原对象的行为，又不必负担那么多的委托动作。

Inappropriate Intimacy（狎昵关系）

有时你会看到两个classes过于亲密，花费太多时间去探究彼此的private成分。如果这发生在两个「人」之间，我们不必做卫道之士；但对于classes，我们希望它们严守清规。

就像古代恋人一样，过份狎昵的classes必须拆散。你可以采用 Move Method 和 Move Field 帮它们划清界线，从而减少狎昵行径。你也可以看看是否运用 Change Bidirectional Association to Unidirectional 让其中一个class对另一个斩断情丝。如果两个实在是情投意合，可以运用Extract Class 把两者共同点提炼到一个安全地点，让它们坦荡地使用这个新class。或者也可以尝试运用 Hide Delegate 让另一个class来为它们传递相思情。

继承（inheritance）往往造成过度亲密，因为subclass对superclass的了解总是超过superclass的主观愿望。如果你觉得该让这个孩子独自生活了，请运用Replace Delegation with Inheritance 让它离开继承体系。

Alternative Classes with Different Interfaces（异曲同工的类）

如果两个函数做同一件事，却有着不同的签名式（signatures），请运用Rename Method 根据它们的用途重新命名。但这往往不够，请反复运用Move Method 将某些行为移入classes，直到两者的协议（protocols ）一致为止。如果你必须重复而赘余地移入代码才能完成这些，或许可运用Extract Superclass 为自己赎 点罪。

Incomplete Library Class（不完美的程序库类）

复用（reuse）常被视为对象的终极目的。我们认为这实在是过度估计了（我们只是使用而己）。但是无可否认，许多编程技术都建立在library classes （程序库类）的基础上，没人敢说是不是我们都把排序算法忘得一干二净了。

library classes构筑者没有未卜先知的能力，我们不能因此责怪他们。毕竟我们自己也几乎总是在系统快要构筑完成的时候才能弄清楚它的设计，所以library 构筑者的任务真的很艰巨。麻烦的是library的形式（form）往往不够好，往往不可能让我们修改其中的classes使它完成我们希望完成的工作。这是否意味那些经过实践检验的战术如 Move Method 等等，如今都派不上用场了？

幸好我们有两个专门应付这种情况的工具。如果你只想修改library classes内的一两 个函数，可以运用 Introduce Foreign Method；如果想要添加一大堆额外行为，就得运用Introduce Local Extension。

Data Class（纯稚的数据类）

所谓Data Class是指：它们拥有一些值域（fields），以及用于访问（读写〕这些值域的函数，除此之外一无长物。这样的classes只是一种「不会说话的数据容器」，它们几乎一定被其他classes过份细琐地操控着。这些classes早期可能拥有public值域，果真如此你应该在别人注意到它们之前，立刻运用Encapsulate Field 将它们封装起来。如果这些classes内含容器类的值域（collection fields），你应该 检査它们是不是得到了恰当的封装；如果没有，就运用 Encapsulate Collection 把它们封装起来。对于那些不该被其他classes修改的值域，请运用 Remove Setting Method。

然后，==找出这些「取值/设值」函数（getting and setting methods）被其他classes运用的地点。尝试以Move Method 把那些调用行为搬移到Data Class来==。如果无法搬移整个函数，就运用 Extract Method 产生一个可被搬移的函数。不久之后你就可以运用Hide Method 把这些「取值/设值」函数隐藏起来了。

Data Class就像小孩子。作为一个起点很好，但若要让它们像「成年（成熟）」的对象那样参与整个系统的工作，它们就必须承担一定责任。

Refused Bequest（被拒绝的遗贈）

Subclasses 应该继承superclasses的函数和数据。但如果它们不想或不需要继承，又该怎么办呢？

按传统说法，这就意味继承体系设计错误。你需要为这个subclass 新建一个兄弟（sibling class），再运用Push Down Method 和 Push Down Field 把所有用不到的函数下推给那兄弟。这样一来superclass就只持有所有subclasses共享的东西。常常你会听到这样的建议：所有superclasses都应该是抽象的（abstract）。

既然使用「传统说法」这个略带贬义的词，你就可以猜到，我们不建议你这么做，起码不建议你每次都这么做。我们经常利用subclassing手法来复用一些行为，并发现这可以很好地应用于日常工作。这也是一种坏味道，我们不否认，但气味通常并不强烈。所以我们说：如果Refused Bequest引起困惑和问题，请遵循传统忠告。但不必认为你每次都得那么做。十有八九这种坏味道很淡，不值得理睬。

如果subclass复用了superclass的行为（实现），却又不愿意支持superclass的接口，Refused Bequest的坏味道就会变得浓烈。拒绝继承superclass的实现，这一点我们不介意；但如果拒绝继承superclass的接口，我们不以为然。不过即使你不愿意继承接口，也不要胡乱修改继承体系，你应该运用Replace Inheritance with Delegation 来达到目的。

Comments（过多的注释）

别担心，我们并不是说你不该写注释。从嗅觉上说，Comments不是一种坏味道；事实上它们还是一种香味呢。我们之所以要在这里提到Comments，因为人们常把它当作除臭剂来使用。常常会有这样的情况：你看到一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。这种情况的发生次数之多，实 在令人吃惊。

Comments可以带我们找到本章先前提到的各种坏味道。找到坏味道后，我们首先应该以各种重构手法把坏味道去除。完成之后我们常常会发现：注释已经变得多余了，因为代码已经清楚说明了一切。

如果你需要注释来解释一块代码做了什么，试试 Extract Method；如果method已经提炼出来，但还是需要注释来解释其行为，试试Rename Method；如果你需要注释说明某些系统的需求规格，试试 Introduce Assertion。

TIP：当你感觉需要撰写注释，请先尝试重构，试着让所有注释都变得多余。

如果你不知道该做什么，这才是注释的良好运用时机。除了用来记述将来的打算之外，注释还可以用来标记你并无十足把握的区域。你可以在注释里写下自己「为什 么做某某事」。这类信息可以帮助将来的修改者，尤其是那些健忘的家伙。

最后

以上就是辛勤柠檬为你收集整理的《重构-改善既有代码的设计》知识精选——代码坏味道章节三 代码的坏味道的全部内容，希望文章能够帮你解决《重构-改善既有代码的设计》知识精选——代码坏味道章节三 代码的坏味道所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。