如果尿布臭了,就换掉它。

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 过多的注释

注释之所以存在是因为代码很糟糕 ,试着重构,让注释变得多余

注释记录将来的打算,没把握的区域,为什么做某某事

说明