1. 成员变量相关
a) 数据泥团
i. 现象或危害：在多个类的成员变量或者多个函数的参数中拥有一些相同的参数，那么这些参数即称之为数据泥团。这种情况的危害在于不利于类和函数的使用。
ii. 处理方法：通过将这些数据封装到一个类中来处理。
b) 基本类型偏执
i. 现象或危害：一组总是被放在一起的基本类型数据。
ii. 处理方法：将这组基本类型数据封闭形成一个类。
c) 令人迷惑的临时变量
i. 现象或危害：有一些成员变量只是为了某些特定情况而存在，如某些函数中使用到多个参数，而编写者为了省事，将这多个参数写成了成员变量，从而可以直接取用。这样的坏处在于不易阅读，会造成类使用者的迷惑。
ii. 处理方法：可以将这些参数提炼到一个新的类中。
2. 成员函数相关
a) 函数过长、注释过多
i. 现象或危害：当一个函数的代码过长，则会影响代码的阅读。而为了使代码可读性好一些则会为代码添加注释。而过多的注释仍然会影响代码的阅读。
ii. 处理方法：处理方法其实很简单就是将一个长的函数拆分成若干个小函数。而这个方法的关键则在于要为这些小函数取一个易于理解的好名字，否则等于是没有进行拆分。一般来说当你需要在代码中添加注释时，就可以尝试将之重构拆分成小函数。
b) 参数过长
i. 现象或危害：显而易见，当一个函数的参数过长，则不利于使用者来调用。
ii. 处理方法：利用容器类或者一个新的类封装这些参数
c) 依恋情结
i. 现象或危害：一个函数放到了一个不属于它的类中，导致其中使用到的数据都在另外一个类中，在调用时它需要频繁的取用另一个类中的数据。
ii. 处理方法：将之放到属于它的类中。看一个函数属于哪一个类的一个判断依据是它使用到哪个类的数据比较多一些。
d) 过度耦合的消息链
i. 现象和危害：所谓消息链就是当一个用户向一个对象请求另一个对象时，另一个对象再向另一个对象请求另外一个对象，如此链接调用下去。
ii. 处理方法：观察消息链最终的对象的作用，最好是将之提炼到一个独立函数中，以此来取代消息链中的若干个环节的请求过程
e) 中间人
i. 现象或危害：就是有一些类的函数将其所有功能都委托给另一个函数来实现，如果这样的委托被过度使用则会导致上述的过度耦合的消息链问题。
ii. 处理方法：移除这些中间人函数
3. 类相关
a) 类过大
i. 现象或危害：类内成员变量过多，代码过多是代码重复、混乱并最终走向死亡的源头。
ii. 处理方法：如果是成员变量过多，则可以将一些变更组合提炼出一个新类，然后根据这些成员变更来确定哪些函数可以移到这个新类中，以此来达到拆分类的目的。
b) 发散式的变化
i. 现象危害：一个类受多种变化的影响，外部变化了，需要修改该类中的多处地方来适应这种变化。
ii. 处理方法：找出由外界变化引起需要修改的地方，将之封装到一处。
c) 霰弹式修改
i. 现象危害：与发散式变化不同，他是指一种外界的变化想起了多个类中的相关部分的修改。
ii. 处理方法：与发散式变化相类似，找出变化引起需要修改的地方，将之封装到一个新类中。
d) 平等继承体系
i. 现象危害：每当你为某个类增加一个子类时，都需要为另一个也相应地增加一个子类。
ii. 处理方法：让一个继承体系的实例引用另一个继承体系的实例。
e) 冗赘类
i. 现象危害：当一个类由于重构等原因导致其失去了存在的意义。
ii. 处理方法：将该类移除。
f) 狎昵关系
i. 现象危害：两个类过多地去访问对方的private内容。
ii. 处理方法：一是重新规划两个类的成员变量和函数来为二者划清界限;二是为二者创建一个父类来封闭他们共同使用的private内容
g) 不完美的类库
i. 现象危害：设计类时将复用性视为终极目的，千方百计的考虑类的可复用性。
ii. 处理方法：利用的意义被高估，设计一个类只要够用就好。
h) 纯粹的数据类
i. 现象危害：一个类只有成员变量和相应的set、get方法，这种类也叫贫血类。
ii. 处理方法：将这些数据移到使用他们的类中。不过如果该贫血类在多处被调用，则有可能不需要进行这个处理。
i) 被拒绝的遗赠
i. 现象危害：一个子类不想从父类中继承某些函数和成员变量。
ii. 处理方法：为这个子类新建一个兄弟类，将父类中放入二者都需要的数据，然后将该子类用不到的数据放到其兄弟类中去。
4. 其它
a) 重复代码：显而易见，应该将这些代码进行合并以减少重复
b) 夸夸其谈未来性：与高估复用性相类似，过多的考虑代码的未来变化。其实大可不必在设计阶段考虑得很完美，在未来可以通过重构的方式来弥补当初设计的缺陷。
