从我们的经验来看，没有任何度量工具比得上一个见识广博的直觉。你必须培养自己的判断力，学会判断一个类有多少实例变量算是太大，一个函数内有多少代码才算太长
复用被视为对象的终极目的，不过我们认为复用的意义经常被高估——大多数对象只要够用就好
重复代码
如果你在一个以上的地方看到相同的程序结构，那么可以肯定：设法将它们合二为一程序会更美好。
过长的函数
“程序越长越难理解”
小函数容易理解的关键在于要有一个好名字，从而让读者无需看其实现逻辑。
原则：每当我们感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，而以其用途（而非实现手法）来命名。我们也可以寻找已有代码中的注释，他们通常能指出代码用途和实现手法之间的语义距离。
条件表达式和循环常常也是需要提炼函数的信号。
过大的类
如果类做的事情太多，其内部往往会出现大量的成员变量。我们可以将几个变量一起提炼到新的类中，提炼的时候我们应该选择类内彼此相关的变量。
如果你的类是个GUI类，你可能需要把数据和行为转移到一个独立的领域对象去
过长的参数列表
函数所需要的参数多数可以在函数宿主类中找到。
如果向已有的对象发送一条请求就可以取代一个参数，那么你就应该重构
发散式的变化
一旦需要修改软件，我们希望能够调到系统的某一点，只在该处做修改。如果不能做到这点就需要重构。针对某一外界变化的所有相应修改，都只应该发生在单一类中，而这个新类内的所有内容都应该反应此变化。
散弹式修改
如果每遇到某种变化，你都必须在许多不同的类内做出小修改，你所面临的就是散弹式修改。这种情况下你应该将所有需要修改的代码放到同一个类中。
依恋情节
函数对某个类的兴趣高过对自己所处类的兴趣。
对此，我们判断的原则是：判断哪个类拥有最多被此函数使用的数据，然后就把这个函数和那些数据摆在一起。最根本的原则是：将总是一起变化的东西放在一块儿。
数据泥团
如果两个或者多个类中有相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据真应该拥有属于它们自己的对象。对象类型的一个极大的价值在于它们模糊甚至打破了横亘于基本数据和体积较大类之间的界限。
switch
switch语句的问题在于重复。你常会发现同样的switch语句散布于不同的地点。如果要为它添加一个新的case子句，就必须找到所有switch语句并修改他们。面向对象中多态的概念可以为此带来优雅的解决办法。
平行的继承体系
如果每当你为某个类增加一个子类，也必须为另一个类相应地增加一个子类。如果你发现某个继承体系的雷鸣称前缀和另一个继承体系的类名称前缀完全相同，那么这就是平行的继承体系。消除这种重复性的一般策略是：让一个继承体系的实例引用另一个继承体系的实例。
冗余类
你所创建的每一个类都得有人去理解它、维护它，这些都是需要成本的。如果一个类所得不值得这样维护，就应该删除
夸夸其谈的未来性
如果你企图以各式各样的钩子和特殊情况来处理一些非必要的事情，而这样做的结果往往是造成系统更难理解和维护。如果所有的特性都有被用到，那就值得做，如果用不到就不值得这样做。
令人迷惑的临时字段
如果类中的某些字段仅仅是某些特殊场景才会用到的（例如类中的某些复杂算法需要许多变量）这时我们可以将其提取到单独的类中
过渡耦合的消息链
如果你看到用户向一个对象请求另一个对象，然后向后者请求另一个对象，然后再请求另一个对象。这就是消息链。对于此问题我们通常的做法是先观察消息链最终获取对象是用于做什么，看能否把其封装到一个函数中，再将函数推到消息链中
中间人
如果某个类接口中有一半的函数都委托给了其他类，这样就是多度运用委托
狎昵关系
如果两个类过于亲密，花费太多的时间去探究彼此的private成分，我们就要考虑重新设计并划清界限。继承往往造成过渡亲密，因为子类对于超类的了解往往超过后者的主观愿望
异曲同工的类
如果两个函数做同一件事却有不同的签名，我们需要根据其实际用途进行重命名。
纯数据类
这样的类是一种不会说话的容器，他们几乎一定被其他类过分细锁地操控着。我们要充分定义内部成员的访问控制权限，将相关数据操作封装在内部
被拒绝的遗赠
如果子类复用了超类的实现，而不愿意支持超类的接口。这时我们需要重新考虑我们的继承体系
过多的注释
你看到一段代码有着常常的注释，然后发现，这些注释之所以存在是因为代码很糟糕。这种情况发生的次数之多实在令人吃惊。
当你感觉需要撰写注释的时候，请先尝试重构，试着让所有的注释都变得多余
网友评论