十四、Temporary Field（令人迷惑的暂时字段）
1、某个实例变量仅为某种特定的情况而设
2、某些实例字段仅为某个函数的复杂算法少传参数而设
将这些变量和相关函数提炼到一个独立的类中。
十五、Message Chains（过度耦合的消息链）
如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后在请求另一个对象……这就是消息链。
实际代码就是一长串的getThis()或者一长串临时变量。
使用隐藏“委托关系”（这个后面会讲）来进行重构。当然了，可以在消息链的任何位置运用。
十六、Middle Man（中间人）
过度运用委托。
1、某个类接口有一半的函数都委托给其他类，这时应“移除中间人”：让客户直接调用委托类。
2、如果只有少数几个函数，那就直接调用
3、如果中间人还有其他行为，以继承取代委托，让委托类继承受托类。
十七、Inappropriate Intimacy（狎昵关系）
两个类过于亲密必须拆散。
1、可以提炼一个类，将两者的共同点提炼到这个类中。
2、可以去掉类之间不必要的关联。
3、将继承改为委托，把子类从继承体系移出
十八、Alternative Classes with Different Interfaces（异曲同工的类）
两个函数做同一件事，但是签名不同。将两个函数合并，并根据用途重新命名。
十九、Incomplete Library Class（不完美的类库）
类库函数构造的不够好，又不能修改它们
1、如果只想修改类的一两个函数，可以引入外加函数。
2、如果想要添加一大堆额外行为，建立一个新类包含这些额外行为，让其成为子类。
二十、Data Class（纯稚的数据类）
所谓Data Class：类只有一些字段，以及访问这些字段的函数。
1、如果拥有public字段，则将其封装起来
2、如果拥有集合类字段，则将其封装起来
3、对于不能修改的字段，去除set方法
二十一、Refused Bequest（被拒绝的遗赠）
派生类仅使用了基类很少一部分成员函数
如果子类复用了父类的行为（实现），却又不愿意支持基类的接口，那就使用委托替代继承。
二十二、Comments（过多的注释）
常常有这种情况：一段代码有着长长的注释，而这些注释之所以存在是因为代码很shit。
这时候我们可以先找到各种“坏味道”，然后重构它。
当你感觉需要撰写注释时，请先尝试重构，试着让所有的注释都变得多余。
记得有一句话是这么说的：注释的最高境界——代码即注释。
当然了，这也不是说，我们不应该写注释。只是注释要写对地方。
小结
到这里所有的“坏味道”已经讲完了。平常我们在写代码的时候，一定要注意这些坏味道。
“如果尿布臭了，就换掉它”。这句话同样适用于我们的代码。
“代码的坏味道”的系列文章主要是对常见的22种坏味道的了解和熟悉，以促使我们在开发过程中，能够经常性地分析和思考程序，寻找已经散发出坏味道的地方并对其进行适当重构，使得代码更加“漂亮”。
在后续的文章中，我会介绍一系列的重构手法来消除这些坏味道。
To Be Continued...