重构的理由

[TOC] ## 代码重复 ## 冗余的子程序 ## 循环过长或嵌套过深 ## 内聚性太差的类 内聚性太差的类如果看到有某个类大包大揽了许多彼此无关的任务，那么这个类就该被拆分成多个类，每个类负责一组具有内在的相互关联的任务。 ## 类的接口未能提供层次一致的抽象 即使是那些从诞生之日起就具有内聚接口的类也可能渐渐失去最初的一致性。 为了维护接口的完整性,程序员常常会在怒之下对类动手,这样的草率修改会使得类随着时间的推移不断地发生变化。最终,类的接口会变成维护的法兰肯斯坦( Frankensteinian,寓人造怪物)恶魔,对程序的可管理性毫无裨益 ## 拥有太多参数的参数列表 ## 类的内部修改往往被局限于某个部分 有时一个类会有这两种或更多独立的功能。如果你发现自己要么修改类里的这一部分,要么修改另一部分,但极少的修改会同时影响类中的两个部分,这就表明该类应该根据相互独立的功能被拆分为多个类。 ## 变化导致对多个类的相同修改 应该使修改仅仅影响一个类 ## 对继承体系的同样修改 ## 同时使用的相关数据并未以类的方式进行组织 如果看到自己常常对同样组数据进行操作,你也应当问问自己是否该将这些数据及其操作组织到一个类里面 ## 成员函数使用其他类的特征比使用自身类的特征还要多 这一状况暗示着这子程序应该被放到另一个类中,然后在原来的类里调用 ## 过多使用基本数据类型 基础类型添加别名,可以预防两个不相等的类型之间比较 ## 子程序命名不恰当 ## 数据成员被设置为公用 ## 某个派生类仅使用了基类的很少一部分成员函数 ## 注释被用于解释难懂的代码 ## 使用了全局变量 ## 在子程序调用前使用了设置代码( setup code) ## 在调用后使用了收尾代码( takedown code)这样的代码应当看作是一种警告