CH03_代码的坏味道（下）

循环语句（Loops）

从最早的编程语言开始，循环就一直是程序设计的核心要素。如今，函数作为一等公民已经得到了广泛的支持，因此我们可以使用以管道取代循环（231）管道操作（如filter和map）可以帮助我们更快地看清被处理的元素以及处理它们的动作。

冗赘的元素（Lazy Element）

程序员定义这样一个类，根本就是一个简单的函数；可能考虑到以后这个类会变复杂、但很长时间这个类都没有变化。或者存在一个类，但随着重构的进行越变越小，最后只剩了一个函数。不论上述哪一种原因，请让这样的程序元素庄严赴义吧。通常你只需要使用内联函数（115）或是内联类（186）。如果这个类处于一个继承体系中，可以使用折叠继承体系（380）。

夸夸其谈通用性（Speculative Generality）

考虑到总有一天需要做这事，并企图以各式各样的钩子和特殊情况来处理一些非必要的事情。这么做的结果往往造成系统更难理解和维护。如果所有装置都会被用到，就值得那么做；如果用不到，就不值得。

如果你的某个抽象类其实没有太大作用，请运用折叠继承体系（380）。不必要的委托可运用内联函数（115）和内联类（186）除掉。如果函数的某些参数未被用上，可以用改变函数声明（124）去掉这些参数。如果有并非真正需要、只是为不知远在何处的将来而塞进去的参数，也应该用改变函数声明（124）去掉。

临时字段（Temporary Field）

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

使用提炼类（182）给这些变量创建一个新类，然后用搬移函数（198）把所有和这些字段相关的代码都放进这个新类。也许你还可以使用引入特例（289）在“变量不合法”的情况下创建一个替代对象，从而避免写出条件式代码。

过长的消息链（Message Chains）

如果看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。在实际代码中看到的可能是一长串取值函数或一长串临时变量。采取这种方式，意味客户端代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端就不得不做出相应修改。

这时候应该使用隐藏委托关系（189）。可以重构消息链上的所有对象，但这么做就会把所有中间对象都变成“中间人”。通常更好的选择是：先观察消息链最终得到的对象是用来干什么的，看看能否以提炼函数（106）把使用该对象的代码提炼到一个独立的函数中，再运用搬移函数（198）把这个函数推入消息链。如果还有许多客户端代码需要访问链上的其他对象，同样添加一个函数来完成此事。

中间人（Middle Man）

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

如果过度使用委托，这时应该使用移除中间人（192），直接和真正负责的对象打交道。如果这样“不干实事”的函数只有少数几个，可以运用内联函数（115）把它们放进调用端。如果这些中间人还有其他行为，可以运用以委托取代超类（399）或者以委托取代子类（381）把它变成真正的对象，这样你既可以扩展原对象的行为，又不必负担那么多的委托动作。

内幕交易（Insider Trading）

软件开发者喜欢在模块之间建起高墙，极其反感在模块之间大量交换数据，因为这会增加模块间的耦合。在实际情况里，一定的数据交换不可避免，但我们必须尽量减少这种情况

如果两个模块数据交换频繁，就应该用搬移函数（198）和搬移字段（207）减少它们的交流。如果两个模块有共同的数据，可以尝试再新建一个模块，把这些共用的数据放在一个管理良好的地方；或者用隐藏委托关系（189），把另一个模块变成两者的中介。

继承常会造成密谋，因为子类对超类的了解总是超过后者的主观愿望。可以运用以委托取代子类（381）或以委托取代超类（399）让它离开继承体系。

过大的类（Large Class）

如果想利用单个类做太多事情，其内往往就会出现太多字段。一旦如此，重复代码也就接踵而至了。

可以运用提炼类（182）将几个变量一起提炼至新类内。提炼时应该选择类内彼此相关的变量，将它们放在一起。如果类内的数个变量有着相同的前缀或后缀，这就意味着有机会把它们提炼到某个组件内。如果这个组件适合作为一个子类，你会发现提炼超类（375）或者以子类取代类型码（362）（其实就是提炼子类）往往比较简单。

类内如果有太多代码，也是代码重复、混乱并最终走向死亡的源头。最简单的解决方案是把多余的东西消弭于类内部。

观察一个大类的使用者，经常能找到如何拆分类的线索。看看使用者是否只用到了这个类所有功能的一个子集，每个这样的子集都可能拆分成一个独立的类。一旦识别出一个合适的功能子集，就试用提炼类（182）、提炼超类（375）或是以子类取代类型码（362）将其拆分出来。

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

使用类的好处之一就在于可以替换：今天用这个类，未来可以换成用另一个类。但只有当两个类的接口一致时，才能做这种替换。可以用改变函数声明（124）将函数签名变得一致。但这往往还不够，请反复运用搬移函数（198）将某些行为移入类中，直到两者的协议一致为止。如果搬移过程造成了重复代码，或许可运用提炼超类（375）补偿一下。

纯数据类（Data Class）

所谓纯数据类是指：它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长物。这样的类只是一种数据容器，它们几乎一定被其他类过分细琐地操控着。这些类早期可能拥有public字段，需要运用封装记录（162）将它们封装起来。对于那些不该被其他类修改的字段，运用移除设值函数（331）。然后，找出这些取值/设值函数被其他类调用的地点。尝试以搬移函数（198）把那些调用行为搬移到纯数据类里来。如果无法搬移整个函数，就运用提炼函数（106）产生一个可被搬移的函数。

纯数据类常常意味着行为被放在了错误的地方。也就是说，只要把处理数据的行为从客户端搬移到纯数据类里来，就能使情况大为改观。但也有例外情况，一个最好的例外情况就是，纯数据记录对象被用作函数调用的返回结果。这种结果数据对象有一个关键的特征：它是不可修改的，不可修改的字段无须封装，使用者可以直接通过字段取得数据，无须通过取值函数。

被拒绝的馈赠（Refused Bequest）

如果子类复用了超类的行为（实现），却又不愿意支持超类的接口，被拒绝的遗赠”的坏味道就会变得很浓烈。

既然不愿意支持超类的接口，就不要使用继承体系，应该运用以委托取代子类（381）或者以委托取代超类（399）彻底划清界限。

注释（Comments）

一段代码有着长长的注释，然后发现，这些注释之所以存在乃是因为代码很糟糕。这种情况的发生次数之多，实在令人吃惊。

如果你需要注释来解释一块代码做了什么，试试提炼函数（106）；如果函数已经提炼出来，但还是需要注释来解释其行为，试试用改变函数声明（124）为它改名；如果你需要注释说明某些系统的需求规格，试试引入断言（302）。