如果尿布臭了,就换掉它。
1.Duplicated Code 重复代码
- Extract Method
- Pull Up Method
- Form Template Method --》 Template Method 模式
- Substitute Algorithm --》 函数算法替代
2.Long Method 过长的函数
“间接层”所带来的全部利益--解释能力、共享能力、选择能力--都是有小函数支持的。
真正关键在于一个好名字。
每当感觉需要以注释来说明点什么的时候,我们就把需要说明的东西写进一个独立函数中, 并以其用途(而非实现手法)命名。
对于参数、临时变量
- Replace Temp with Query
- Introduce Parameter Object
- Preserver Whole Object
- Replace Method with Method Object
如何确定该提炼哪段代码:寻找注释
条件表达式 和 循环 常常也是提炼的信号
3.Large Class 过大的类
根据客户端的使用,先提炼一个接口
4.Long Parameter List 过长的参数列
函数需要的东西多半可以在函数的宿主类中找到
5.Divergent Change 发散式变化
一个类受多种变化的影响
6.Shotgun Surgery 散弹式变化
一种变化引发多个类相应修改
7.Feature Envy 依恋情结
函数对某个类的兴趣高过对自己所处类的兴趣 --焦点 数据
8.Data Clumps 数据泥团
两个类中相同的字段、许多函数签名中相同的参数
9.Primitive Obsession 基本类型偏执
如果有一组总是被放在一起的字段,可以抽到一个类中。
如果在参数列表中看到基本类型数据,试试Introduce Parameter Object
如果自己正从数组中挑选数据 可以运行 Replace Array with Object
10.Switch Statements switch语句
11.Parallel Inheritance Hierarchies 平行继承体系
引用另一个类
12.Lazy Class 冗赘类
13.Speculation Generality 夸夸其谈未来性
14.Temporary Field 令人迷惑的暂时字段
Null对象
15.Message Chains 过度耦合的消息链
Hide Delegate 可以在消息链的不同位置进行这种重构手法
16.Middle Man 中间人
过度运用委托,那么干脆把委托干掉
17.Inappropriate Intimate 狎昵关系
继承有时造成过度亲密,可以独立子类
18.Alternative Classes with Different Interface 异曲同工的类
函数做同一件事,却有不同的签名
19.Incomplete Library Class 不完美的类库
- Introduce Foreign Method
- Introduce Local Extension
20.Data Class 纯稚的数据类
调用行为搬移到Data Class类,必须承担一定责任
21.Refuse Bequest 被拒绝的馈赠
子类不想继承超类的函数和数据
22.Comments 过多的注释
注释之所以存在是因为代码很糟糕 ,试着重构,让注释变得多余
注释记录将来的打算,没把握的区域,为什么做某某事
说明
《重构-改善既有代码的设计》Martin Fowler 摘要: 第三章 代码的坏味道
你也可以访问:http://txidol.github.io 获取更多的信息