如果尿布臭了,就换掉它。
“间接层”所带来的全部利益--解释能力、共享能力、选择能力--都是有小函数支持的。
真正关键在于一个好名字。
每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中, 并以其用途(而非实现手法)命名。
对于参数、临时变量
如何确定该提炼哪段代码:寻找注释
条件表达式 和 循环 常常也是提炼的信号
根据客户端的使用,先提炼一个接口
函数需要的东西多半可以在函数的宿主类中找到
一个类受多种变化的影响
一种变化引发多个类相应修改
函数对某个类的兴趣高过对自己所处类的兴趣 --焦点 数据
两个类中相同的字段、许多函数签名中相同的参数
如果有一组总是被放在一起的字段,可以抽到一个类中。
如果在参数列表中看到基本类型数据,试试Introduce Parameter Object
如果自己正从数组中挑选数据 可以运行 Replace Array with Object
引用另一个类
Null对象
Hide Delegate 可以在消息链的不同位置进行这种重构手法
过度运用委托,那么干脆把委托干掉
继承有时造成过度亲密,可以独立子类
函数做同一件事,却有不同的签名
调用行为搬移到Data Class类,必须承担一定责任
子类不想继承超类的函数和数据
注释之所以存在是因为代码很糟糕 ,试着重构,让注释变得多余
注释记录将来的打算,没把握的区域,为什么做某某事
《重构-改善既有代码的设计》Martin Fowler 摘要: 第三章 代码的坏味道
原文:http://blog.csdn.net/tanxiang21/article/details/27485737