如果是尿布抽了，就换掉它。 —— Beck奶奶

3.1 Duplicated Code

最单纯的Duplicated Code是同一个类的两个函数含有相同的表达式；另一种常见的情况就是两个互为兄弟的子类内含相同的表达式，构筑超类或者使用模板方法；如果两个毫不相关的类出现Dulicated Code，提取独立类。

3.2 Long Method

拥有短函数的对象会获得比较好、比较长。间接层所能带来的全部利益——解释能力、共享能力、选择能力——都是由小型函数支持的。

3.3 Large Class

如果单个类想做太多的事情，期内往往会有太多的实例变量。这往往意味着Duplicated Code。

3.4 Long Parameter List

太长的参数无法理解，太多的参数同时也会容易造成前后不一致。

3.5 Divergent Change（发散式修改）

我们希望软件能够更容易被修改。如果某个类经常因为不同的原因在不同的方向上发生变化。最好能将类切开，这也是遵循单一职责原则。

3.6 Shotgun Surgery（散弹式修改）

Shotgun Surgery和Divergent Change类似，但是恰恰相反。如果每遇到某种变化，你都必须在许多不同类内做出许多小修改。
　　总之，Divergent Change是指一个类受多种变化影响。Shortgun Surgery则是指一个变化引起多个类相应修改。

3.7 Feature Envy（依恋情节）

对象技术的全部要点在于：这是一种“将数据和对数据的操作行为包装在一起”的技术。有一种经典的气味：函数对某个类的兴趣搞过对自己所处类的兴趣。例如：某个类为了计算某个值，从某个类中获取几乎半打的取值函数。这种函数，应该将这个函数移动到它应该在的地方。
判断类的地址的原则：判断哪个类拥有最多被此函数使用的数据，然后该函数就乖乖去了那里。Strategy和Visitor就是对抗Divergent Change。最根本的原则：将总是一起变化的东西放在一起，保持变化永远只在一处发生。当然，你不得不多加一层抽象层次。

3.8 Data Clumps

数据项就像小孩子，喜欢成群结队地待在一块儿。常常可以在很多地方看到相同的三四项数据：两个类中的相同字段、许多函数签名中的参数。这些总是绑定在一起出现的数据真应该拥有属于它们自己的对象。
　　一个好的评判方法：删除众多数据中的一项。这么做，其他数据没有失去意义？如果不再有意义，这就是明确的意义，告诉你应该为他们产生一个新对象。

3.9 Primitive Obsession（基本类型偏执）

大多数编程环境都有两种数据：结构类型允许你将数据组织成有意义的形式；基本类型则是构筑结构类型的积木块。结构总是会带来一定的额外开销。他们可能代表着数据中的表，如果仅仅为了做一两件事而穿件结构类型也可能显得太麻烦了。

3.10 Switch Statement（惊悚的switch）

面向对象程序的一个最棉线特征就是：少用switch（或case）语句。
　　大多数的时候，一看到switch语句，你就应该考虑以多态来替代它；但是在单一函数中有些选择事例，且并不想改动它们，那么多态就有点杀鸡用牛刀了。

3.11 Parallel Inheritance Hierarchies（平行继承体系）

其实是Shotgun Surgery的特殊情况。即一个类增加一个子类，另一个类也必须增加一个子类。
　　一般则略：让一个继承体系的实例引用另一个体系的实例。

3.12 Lazy Class（冗余类）

如果一个类不值其身价，它就应该消失。

3.13 Speculative Generality（夸夸其谈未来性）

因为主观臆测的未来性（未来某天我们需要做这件事情），并其余以各种各样的钩子和特殊情况来处理一些非必要的事情。
　　注意：当函数或者类的唯一用户是测试用例，坏味道就飘出来了。

3.14 Temporary Field（令人迷惑的临时字段）

对象内某个实例变量仅为某特定情况而设。这样的代码会让让人无法理解，通常认为对象在所有时候都需要它所有变量。猜测变量的用途会让人crazy。

3.15 Message Chain（过度偶尔得消息链）

如果你可以看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。采取这种方式，意味着用户代码将与查找过程中的导航结构紧密耦合。一旦对象间的关系发生任何变化，客户端也的变化。
　　可以使用消息队列模式来进行重构。

3.16 Middle Man

对象的基本特征之一就是封装——对外部空间隐藏起内部实现细节。封装也代表着委托。但是也有时候会成为过度的委托。我们会看到某个类接口将其一半的实现委托给其他类。

3.17 Inappropriate Intimacy（狎昵关系）

有时你会看到两个类过于亲密，花费太多时间探究彼此的private成分。过分狎昵必须分开。集成往往造成过度亲密，因为子类对超类的了解总是超过后者的主观愿望。需要的时候，让类离开类继承关系链。

3.18 Alternative Classes with Diffierent Interaces（异曲同工的类）

如果两个函数做同一件事情，却有着不同的签名，请根据用于合并和修改。

3.19 Incomplete Library Class（不完美的库类）

复用被视为对象的终极目的。不过，往往复用的意义经常被高估——大多数对象只要够用就好。有时候需要根据需要修改类库。

3.20 Data Class（纯稚的数据类）

Data Class是指它们拥有一些字段，以及用于访问（读写）这些字段的函数，除此之外一无长处。这种类往往被其他类过分操纵。这些类可能拥有public字段，果真如此，需要在别人注意到之前封装起来；如果这些类内含容器类的字段，你应该前叉它们是否得到了恰当的封装。如果没有则正确封装它们。然后找出取值/设值函数被其他类运用的地点。尝试以Move Method将调用行为移动到Data Class中。

3.21 Refused Bequest（被拒绝的遗赠）

子类应该继承超类的函数和数据。但是如果不想继承所有，怎么选择其中一部分。这就意味着继承体系设计错误。给子类设计兄弟类，下移动一部分字段到兄弟类中。从而正确构建体系。

3.22 Comments（过多的注释）

Comments本身是带着香味，然而不恰当的注释是相当臭气味。只有当不知道如何重构的时候，使用注释才是优质的方式。