12、Lazy Class – 冗赘类<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

对于几乎没有用的类，运用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，使其拥有有一个能说明其行为的类名或方法名，程序可读性会大大增强