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
