12、Lazy Class – 冗赘类
对于几乎没有用的类，运用inline class 将其功能移动。去除这些不值得维护的类。
13、Speculative Generality – 夸夸其谈未来性
对于你现在用不到，觉得总有一天会用到的代码，要警惕。用不上的装置总会挡我们的路，所以要尽量搬开。例如，没有太大作用的abstract class，非必要的委托，没有用到的函数参数，或者是函数的名称带有多余的抽像的意味。
14、Temporary Field – 令人迷惑的暂时值域
如果某些变量只是为了某种特定情况而设的，常会让人不理解
15、Message Chains – 过度耦合的消息链
你常会看到用户向一个对象请求另一个对象，然后再向后者请求另一对像，然后再继续…形成了一个强耦合的消息链。一旦对像间的关系发生任何变化，客户不得不做出大量修改。
16、Middle Man –中间转手人
Encapsulation – 封装，对外部世界隐藏内部细节。封装常常伴随delegation（委托），但如果被过度使用，就必须得重新考虑。如果你看到某个class中有一半的函数都委托给其它class，这时就是强烈地信号。
17、Inappropriate Intimacy – 狎昵关系
二个类之间的关系联系太过紧密，造成强耦合。一般来讲，继承往往会造成这样结果，因为subclass对superclass的了解总是超过superclass的主观愿望。
18、Alternative Classed with Different Interfaces? -- 异曲同工的类
二个函数做同样的事，却有着不同的名字。你该知道怎么处理了吧。
19、Incomplete Library Class – 不完美的程序库类
我们在运用程序类库的时候，发现它并不是真正适合需要。
20、Data Class 纯稚的数据类
找到Data Class 中可能存在的public的值域，如果它的fields中存在容器类，就要小心地检查是不是得到了有效的封装。
21、Refused Bequest – 被拒绝的遗赠
Subclasses 应该继承superclass的函数和数据，但是如果subclass并不需要superclass的中某些功能，该怎么办呢。
22、Comments – 过多的注释
这里讲并不是你不应当写注释，而是说，如果一段代码有着长长的注释，实际上说明这段代码是不容易看懂的，如果到处都需要大段的注释，那整体程序的可读性就大大困难；如果你一定需要一段注释来说明，那么先试着重构，把可提出去Method 找出来，如果这之后仍然需要注释来解释其行为，那就要试着Rename，使其拥有有一个能说明其行为的类名或方法名，程序可读性会大大增强
本文转自 wenyan 51CTO博客，原文链接:http://blog.51cto.com/wenyan/9953