曾用名:搬移函数(Move Method)
![](https://box.kancloud.cn/8564f3485c61d0660f419a119f3375fa_605x117.jpeg)
```
class Account {
get overdraftCharge() {...}
```
![](https://box.kancloud.cn/a3bed334e2e1f6d1a46c5039deb25af9_91x152.jpeg)
```
class AccountType {
get overdraftCharge() {...}
```
### 动机
模块化是优秀软件设计的核心所在,好的模块化能够让我在修改程序时只需理解程序的一小部分。为了设计出高度模块化的程序,我得保证互相关联的软件要素都能集中到一块,并确保块与块之间的联系易于查找、直观易懂。同时,我对模块设计的理解并不是一成不变的,随着我对代码的理解加深,我会知道那些软件要素如何组织最为恰当。要将这种理解反映到代码上,就得不断地搬移这些元素。
任何函数都需要具备上下文环境才能存活。这个上下文可以是全局的,但它更多时候是由某种形式的模块所提供的。对一个面向对象的程序而言,类作为最主要的模块化手段,其本身就能充当函数的上下文;通过嵌套的方式,外层函数也能为内层函数提供一个上下文。不同的语言提供的模块化机制各不相同,但这些模块的共同点是,它们都能为函数提供一个赖以存活的上下文环境。
搬移函数最直接的一个动因是,它频繁引用其他上下文中的元素,而对自身上下文中的元素却关心甚少。此时,让它去与那些更亲密的元素相会,通常能取得更好的封装效果,因为系统别处就可以减少对当前模块的依赖。
同样,如果我在整理代码时,发现需要频繁调用一个别处的函数,我也会考虑搬移这个函数。有时你在函数内部定义了一个帮助函数,而该帮助函数可能在别的地方也有用处,此时就可以将它搬移到某些更通用的地方。同理,定义在一个类上的函数,可能挪到另一个类中去更方便我们调用。
是否需要搬移函数常常不易抉择。为了做出决定,我需要仔细检查函数当前上下文与目标上下文之间的区别,需要查看函数的调用者都有谁,它自身又调用了哪些函数,被调用函数需要什么数据,等等。在搬移过程中,我通常会发现需要为一整组函数创建一个新的上下文,此时就可以用函数组合成类(144)或提炼类(182)创建一个。尽管为函数选择一个最好的去处不太容易,但决定越难做,通常说明“搬移这个函数与否”的重要性也越低。我发现好的做法是先把函数安置到某一个上下文里去,这样我就能发现它们是否契合,如果不太合适我可以再把函数搬移到别的地方。
### 做法
- 检查函数在当前上下文里引用的所有程序元素(包括变量和函数),考虑是否需要将它们一并搬移
> 如果发现有些被调用的函数也需要搬移,我通常会先搬移它们。这样可以保证移动一组函数时,总是从依赖最少的那个函数入手。
>
> 如果该函数拥有一些子函数,并且它是这些子函数的唯一调用者,那么你可以先将子函数内联进来,一并搬移到新家后再重新提炼出子函数。
- 检查待搬移函数是否具备多态性。
> 在面向对象的语言里,还需要考虑该函数是否覆写了超类的函数,或者为子类所覆写。
- 将函数复制一份到目标上下文中。调整函数,使它能适应新家。
> 如果函数里用到了源上下文(source context)中的元素,我就得将这些元素一并传递过去,要么通过函数参数,要么是将当前上下文的引用传递到新的上下文那边去。
>
> 搬移函数通常意味着,我还得给它起个新名字,使它更符合新的上下文。
- 执行静态检查。
- 设法从源上下文中正确引用目标函数。
- 修改源函数,使之成为一个纯委托函数。
- 测试。
- 考虑对源函数使用内联函数(115)
> 也可以不做内联,让源函数一直做委托调用。但如果调用方直接调用目标函数也不费太多周折,那么最好还是把中间人移除掉。
### 范例:搬移内嵌函数至顶层
让我用一个函数来举例。这个函数会计算一条GPS轨迹记录(track record)的总距离(total distance)。
```
function trackSummary(points) {
const totalTime = calculateTime();
const totalDistance = calculateDistance();
const pace = totalTime / 60 / totalDistance ;
return {
time: totalTime,
distance: totalDistance,
pace: pace
};
function calculateDistance() {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
}
function distance(p1,p2) { ... }
function radians(degrees) { ... }
function calculateTime() { ... }
}
```
我希望把`calculateDistance`函数搬移到顶层,这样我就能单独计算轨迹的距离,而不必算出汇总报告(summary)的其他部分。
我先将函数复制一份到顶层作用域中:
```
function trackSummary(points) {
const totalTime = calculateTime();
const totalDistance = calculateDistance();
const pace = totalTime / 60 / totalDistance ;
return {
time: totalTime,
distance: totalDistance,
pace: pace
};
function calculateDistance() {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
}
...
function distance(p1,p2) { ... }
function radians(degrees) { ... }
function calculateTime() { ... }
}
function top_calculateDistance() {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
}
```
复制函数时,我习惯为函数一并改个名,这样可让“它们有不同的作用域”这个信息显得一目了然。现在我还不想花费心思考虑它正确的名字该是什么,因此我暂且先用一个临时的名字。
此时代码依然能正常工作,但我的静态分析器要开始抱怨了,它说新函数里多了两个未定义的符号,分别是`distance`和`points`。对于`points`,自然是将其作为函数参数传进来。
```
function top_calculateDistance(points) {
let result =0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
}
```
至于`distance`,虽然我也可以将它作为参数传进来,但也许将其计算函数`calculate Distance`一并搬移过来会更合适。该函数的代码如下。
##### function trackSummary...
```
function distance(p1,p2) {
const EARTH_RADIUS = 3959; // in miles
const dLat = radians(p2.lat) - radians(p1.lat);
const dLon = radians(p2.lon) - radians(p1.lon);
const a = Math.pow(Math.sin(dLat / 2),2)
+ Math.cos(radians(p2.lat))
* Math.cos(radians(p1.lat))
* Math.pow(Math.sin(dLon / 2), 2);
const c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a));
return EARTH_RADIUS * c;
}
function radians(degrees) {
return degrees * Math.PI / 180;
}
```
我留意到`distance`函数中只调用了`radians`函数,后者已经没有再引用当前上下文里的任何元素。因此与其将`radians`作为参数,我更倾向于将它也一并搬移。不过我不需要一步到位,我们可以先将这两个函数从当前上下文中搬移进`calculateDistance`函数里:
```
function trackSummary(points) {
const totalTime = calculateTime();
const totalDistance = calculateDistance();
const pace = totalTime / 60 / totalDistance ;
return {
time: totalTime,
distance: totalDistance,
pace: pace
};
function calculateDistance() {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
function distance(p1,p2) { ... }
function radians(degrees) { ... }
}
```
这样做的好处是,我可以充分发挥静态检查和测试的作用,让它们帮我检查有无遗漏的东西。在这个实例中一切顺利,因此,我可以放心地将这两个函数直接复制到`top_calculateDistance`中:
```
function top_calculateDistance(points) {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
function distance(p1,p2) { ... }
function radians(degrees) { ... }
}
```
这次复制操作同样不会改变程序现有行为,但给了静态分析器更多介入的机会,增加了暴露错误的概率。假如我在上一步没有发现`distance`函数内部还调用了`radians`函数,那么这一步就会被分析器检查出来。
现在万事俱备,是时候端出主菜了——我要在原`calculateDistance`函数体内调用`top_calculateDistance`函数:
```
function trackSummary(points) {
const totalTime = calculateTime();
const totalDistance = calculateDistance();
const pace = totalTime / 60 / totalDistance ;
return {
time: totalTime,
distance: totalDistance,
pace: pace
};
function calculateDistance() {
return top_calculateDistance(points);
}
```
接下来最重要的事是要运行一遍测试,看看功能是否仍然完整,函数在其新家待得是否舒适。
测试通过后,便算完成了主要任务,就好比搬家,现在大箱小箱已经全搬到新家,接下来就是将它们拆箱复位了。第一件事是决定还要不要保留原来那个只起委托作用的函数。在这个例子中,原函数的调用点不多,作为嵌套函数它们的作用范围通常也很小,因此我觉得这里大可直接移除原函数。
```
function trackSummary(points) {
const totalTime = calculateTime();
const totalDistance = top_calculateDistance(points);
const pace = totalTime / 60 / totalDistance ;
return {
time: totalTime,
distance: totalDistance,
pace: pace
};
}
```
同时,也该是时候为这个函数认真想个名字了。因为顶层函数拥有最高的可见性,因此取个好名非常重要。`totalDistance`听起来不错,但还不能马上用这个名字,因为`trackSummary`函数中有一个同名的变量——我不觉得这个变量有保留的价值,因此我们先用内联变量(123)处理它,之后再使用改变函数声明(124):
```
function trackSummary(points) {
const totalTime = calculateTime();
const pace = totalTime / 60 / totalDistance(points) ;
return {
time: totalTime,
distance: totalDistance(points),
pace: pace
};
}
function totalDistance(points) {
let result = 0;
for (let i = 1; i < points.length; i++) {
result += distance(points[i-1], points[i]);
}
return result;
}
```
如果出于某些原因,实在需要保留该变量,那么我建议将该变量改个其他的名字,比如`totalDistanceCache`或`distance`等。
由于`distance`函数和`radians`函数并未使用`totalDistance`中的任何变量或函数,因此我倾向于把它们也提升到顶层,也就是4个方法都放置在顶层作用域上。
```
function trackSummary(points) { ... }
function totalDistance(points) { ... }
function distance(p1,p2) { ... }
function radians(degrees) { ... }
```
有些人则更倾向于将`distance`和`radians`函数保留在`totalDistance`内,以便限制它们的可见性。在某些语言里,这个顾虑也许有其道理,但新的ES 2015规范为JavaScript提供了一个美妙的模块化机制,利用它来控制函数的可见性是再好不过了。通常来说,我对嵌套函数还是心存警惕的,因为很容易在里面编写一些私有数据,并且在函数之间共享,这可能会增加代码的阅读和重构难度。
### 范例:在类之间搬移函数
在类之间搬移函数也是一种常见场景,下面我将用一个表示“账户”的`Account`类来讲解。
##### class Account...
```
get bankCharge() {
let result = 4.5;
if (this._daysOverdrawn > 0) result += this.overdraftCharge;
return result;
}
get overdraftCharge() {
if (this.type.isPremium) {
const baseCharge = 10;
if (this.daysOverdrawn <= 7)
return baseCharge;
else
return baseCharge + (this.daysOverdrawn - 7) * 0.85;
}
else
return this.daysOverdrawn * 1.75;
}
```
上面的代码会根据账户类型(account type)的不同,决定不同的“透支金额计费”算法。因此,很自然会想到将`overdraftCharge`函数搬移到`AccountType`类去。
第一步要做的是:观察被`overdraftCharge`使用的每一项特性,考虑是否值得将它们与`overdraftCharge`函数一起移动。此例中我需要让`daysOverdrawn`字段留在`Account`类中,因为它会随不同种类的账户而变化。
然后,我将`overdraftCharge`函数主体复制到`AccountType`类中,并做相应调整。
##### class AccountType...
```
overdraftCharge(daysOverdrawn) {
if (this.isPremium) {
const baseCharge = 10;
if (daysOverdrawn <= 7)
return baseCharge;
else
return baseCharge + (daysOverdrawn - 7) * 0.85;
}
else
return daysOverdrawn * 1.75;
}
```
为了使函数适应这个新家,我必须决定如何处理两个作用范围发生改变的变量。`isPremium`如今只需要简单地从`this`上获取,但`daysOverdrawn`怎么办呢?我是直接传值,还是把整个`account`对象传过来?为了方便,我选择先简单传一个值,不过如果后续还需要账户(account)对象上除了`daysOverdrawn`以外的更多数据,例如需要根据账户类型(account type)来决定如何从账户(`account`)对象上取用数据时,那么我很可能会改变主意,转而选择传入整个`account`对象。
完成函数复制后,我会将原来的方法代之以一个委托调用。
##### class Account...
```
get bankCharge() {
let result = 4.5;
if (this._daysOverdrawn > 0) result += this.overdraftCharge;
return result;
}
get overdraftCharge() {
return this.type.overdraftCharge(this.daysOverdrawn);
}
```
然后下一件需要决定的事情是,是保留`overdraftCharge`这个委托函数,还是直接内联它?内联的话,代码会变成下面这样。
##### class Account...
```
get bankCharge() {
let result = 4.5;
if (this._daysOverdrawn > 0)
result += this.type.overdraftCharge(this.daysOverdrawn);
return result;
}
```
在早先的步骤中,我将`daysOverdrawn`作为参数直接传递给`overdraftCharge`函数,但如若账户(account)对象上有很多数据需要传递,那我就比较倾向于直接将整个对象作为参数传递过去:
##### class Account...
```
get bankCharge() {
let result = 4.5;
if (this._daysOverdrawn > 0) result += this.overdraftCharge;
return result;
}
get overdraftCharge() {
return this.type.overdraftCharge(this);
}
```
##### class AccountType…
```
overdraftCharge(account) {
if (this.isPremium) {
const baseCharge = 10;
if (account.daysOverdrawn <= 7)
return baseCharge;
else
return baseCharge + (account.daysOverdrawn - 7) * 0.85;
}
else
return account.daysOverdrawn * 1.75;
}
```
- 第1章 重构,第一个示例
- 1.1 起点
- 1.2 对此起始程序的评价
- 1.3 重构的第一步
- 1.4 分解statement函数
- 1.5 进展:大量嵌套函数
- 1.6 拆分计算阶段与格式化阶段
- 1.7 进展:分离到两个文件(和两个阶段)
- 1.8 按类型重组计算过程
- 1.9 进展:使用多态计算器来提供数据
- 1.10 结语
- 第2章 重构的原则
- 2.1 何谓重构
- 2.2 两顶帽子
- 2.3 为何重构
- 2.4 何时重构
- 2.5 重构的挑战
- 2.6 重构、架构和YAGNI
- 2.7 重构与软件开发过程
- 2.8 重构与性能
- 2.9 重构起源何处
- 2.10 自动化重构
- 2.11 延展阅读
- 第3章 代码的坏味道
- 3.1 神秘命名(Mysterious Name)
- 3.2 重复代码(Duplicated Code)
- 3.3 过长函数(Long Function)
- 3.4 过长参数列表(Long Parameter List)
- 3.5 全局数据(Global Data)
- 3.6 可变数据(Mutable Data)
- 3.7 发散式变化(Divergent Change)
- 3.8 霰弹式修改(Shotgun Surgery)
- 3.9 依恋情结(Feature Envy)
- 3.10 数据泥团(Data Clumps)
- 3.11 基本类型偏执(Primitive Obsession)
- 3.12 重复的switch (Repeated Switches)
- 3.13 循环语句(Loops)
- 3.14 冗赘的元素(Lazy Element)
- 3.15 夸夸其谈通用性(Speculative Generality)
- 3.16 临时字段(Temporary Field)
- 3.17 过长的消息链(Message Chains)
- 3.18 中间人(Middle Man)
- 3.19 内幕交易(Insider Trading)
- 3.20 过大的类(Large Class)
- 3.21 异曲同工的类(Alternative Classes with Different Interfaces)
- 3.22 纯数据类(Data Class)
- 3.23 被拒绝的遗赠(Refused Bequest)
- 3.24 注释(Comments)
- 第4章 构筑测试体系
- 4.1 自测试代码的价值
- 4.2 待测试的示例代码
- 4.3 第一个测试
- 4.4 再添加一个测试
- 4.5 修改测试夹具
- 4.6 探测边界条件
- 4.7 测试远不止如此
- 第5章 介绍重构名录
- 5.1 重构的记录格式
- 5.2 挑选重构的依据
- 第6章 第一组重构
- 6.1 提炼函数(Extract Function)
- 6.2 内联函数(Inline Function)
- 6.3 提炼变量(Extract Variable)
- 6.4 内联变量(Inline Variable)
- 6.5 改变函数声明(Change Function Declaration)
- 6.6 封装变量(Encapsulate Variable)
- 6.7 变量改名(Rename Variable)
- 6.8 引入参数对象(Introduce Parameter Object)
- 6.9 函数组合成类(Combine Functions into Class)
- 6.10 函数组合成变换(Combine Functions into Transform)
- 6.11 拆分阶段(Split Phase)
- 第7章 封装
- 7.1 封装记录(Encapsulate Record)
- 7.2 封装集合(Encapsulate Collection)
- 7.3 以对象取代基本类型(Replace Primitive with Object)
- 7.4 以查询取代临时变量(Replace Temp with Query)
- 7.5 提炼类(Extract Class)
- 7.6 内联类(Inline Class)
- 7.7 隐藏委托关系(Hide Delegate)
- 7.8 移除中间人(Remove Middle Man)
- 7.9 替换算法(Substitute Algorithm)
- 第8章 搬移特性
- 8.1 搬移函数(Move Function)
- 8.2 搬移字段(Move Field)
- 8.3 搬移语句到函数(Move Statements into Function)
- 8.4 搬移语句到调用者(Move Statements to Callers)
- 8.5 以函数调用取代内联代码(Replace Inline Code with Function Call)
- 8.6 移动语句(Slide Statements)
- 8.7 拆分循环(Split Loop)
- 8.8 以管道取代循环(Replace Loop with Pipeline)
- 8.9 移除死代码(Remove Dead Code)
- 第9章 重新组织数据
- 9.1 拆分变量(Split Variable)
- 9.2 字段改名(Rename Field)
- 9.3 以查询取代派生变量(Replace Derived Variable with Query)
- 9.4 将引用对象改为值对象(Change Reference to Value)
- 9.5 将值对象改为引用对象(Change Value to Reference)
- 第10章 简化条件逻辑
- 10.1 分解条件表达式(Decompose Conditional)
- 10.2 合并条件表达式(Consolidate Conditional Expression)
- 10.3 以卫语句取代嵌套条件表达式(Replace Nested Conditional with Guard Clauses)
- 10.4 以多态取代条件表达式(Replace Conditional with Polymorphism)
- 10.5 引入特例(Introduce Special Case)
- 10.6 引入断言(Introduce Assertion)
- 第11章 重构API
- 11.1 将查询函数和修改函数分离(Separate Query from Modifier)
- 11.2 函数参数化(Parameterize Function)
- 11.3 移除标记参数(Remove Flag Argument)
- 11.4 保持对象完整(Preserve Whole Object)
- 11.5 以查询取代参数(Replace Parameter with Query)
- 11.6 以参数取代查询(Replace Query with Parameter)
- 11.7 移除设值函数(Remove Setting Method)
- 11.8 以工厂函数取代构造函数(Replace Constructor with Factory Function)
- 11.9 以命令取代函数(Replace Function with Command)
- 11.10 以函数取代命令(Replace Command with Function)
- 第12章 处理继承关系
- 12.1 函数上移(Pull Up Method)
- 12.2 字段上移(Pull Up Field)
- 12.3 构造函数本体上移(Pull Up Constructor Body)
- 12.4 函数下移(Push Down Method)
- 12.5 字段下移(Push Down Field)
- 12.6 以子类取代类型码(Replace Type Code with Subclasses)
- 12.7 移除子类(Remove Subclass)
- 12.8 提炼超类(Extract Superclass)
- 12.9 折叠继承体系(Collapse Hierarchy)
- 12.10 以委托取代子类(Replace Subclass with Delegate)
- 12.11 以委托取代超类(Replace Superclass with Delegate)
- 参考文献
- 重构列表
- 坏味道与重构手法速查表