反向重构：函数下移（359）  ``` class Employee {...} class Salesman extends Employee { 　get name() {...} } class Engineer extends Employee { 　get name() {...} } ```  ``` class Employee { 　get name() {...} } class Salesman extends Employee {...} class Engineer extends Employee {...} ``` ### 动机 避免重复代码是很重要的。重复的两个函数现在也许能够正常工作，但假以时日却只会成为滋生bug的温床。无论何时，只要系统内出现重复，你就会面临“修改其中一个却未能修改另一个”的风险。通常，找出重复也有一定的难度。 如果某个函数在各个子类中的函数体都相同（它们很可能是通过复制粘贴得到的），这就是最显而易见的函数上移适用场合。当然，情况并不总是如此明显。我也可以只管放心地重构，再看看测试程序会不会发牢骚，但这就需要对我的测试有充分的信心。我发现，观察这些可能重复的函数之间的差异往往大有收获：它们经常会向我展示那些我忘记测试的行为。 函数上移常常紧随其他重构而被使用。也许我能找出若干个身处不同子类内的函数，而它们又可以通过某种形式的参数调整成为相同的函数。这时候，最简单的办法就是先分别对这些函数应用函数参数化（310），然后应用函数上移。 函数上移过程中最麻烦的一点就是，被提升的函数可能会引用只出现于子类而不出现于超类的特性。此时，我就得用字段上移（353）和函数上移先将这些特性（类或者函数）提升到超类。 如果两个函数工作流程大体相似，但实现细节略有差异，那么我会考虑先借助塑造模板函数（Form Template Method）\[mf-ft\]构造出相同的函数，然后再提升它们。 ### 做法 - 检查待提升函数，确定它们是完全一致的。 > 如果它们做了相同的事情，但函数体并不完全一致，那就先对它们进行重构，直到其函数体完全一致。 - 检查函数体内引用的所有函数调用和字段都能从超类中调用到。 - 如果待提升函数的签名不同，使用改变函数声明（124）将那些签名都修改为你想要在超类中使用的签名。 - 在超类中新建一个函数，将某一个待提升函数的代码复制到其中。 - 执行静态检查。 - 移除一个待提升的子类函数。 - 测试。 - 逐一移除待提升的子类函数，直到只剩下超类中的函数为止。 ### 范例 我手上有两个子类，它们之中各有一个函数做了相同的事情： ##### class Employee extends Party... ``` get annualCost() { return this.monthlyCost * 12; } ``` ##### class Department extends Party... ``` get totalAnnualCost() { return this.monthlyCost * 12; } ``` 检查两个类的函数时我发现，两个函数都引用了`monthlyCost`属性，但后者并未在超类中定义，而是在两个子类中各自定义了一份实现。因为JavaScript是动态语言，这样做没有问题；但如果是在一门静态语言里，我就必须将`monthlyCost`声明为`Party`类上的抽象函数，否则编译器就会报错。 两个函数各有不同的名字，因此第一步是用改变函数声明（124）统一它们的函数名。 ##### class Department... ``` get annualCost() { return this.monthlyCost * 12; } ``` 然后，我从其中一个子类中将`annualCost`函数复制到超类。 ##### class Party... ``` get annualCost() { return this.monthlyCost * 12; } ``` 在静态语言里，做完这一步我就可以编译一次，确保超类函数的所有引用都能正常工作。但这是在JavaScript里，编译显然帮不上什么忙，因此我直接先从`Employee`中移除`annualCost`函数，测试，接着移除`Department`类中的`annualCost`函数。 这项重构手法至此即告完成，但还有一个遗留问题需要解决：`annualCost`函数中调用了`monthlyCost`，但后者并未在`Party类`中显式声明。当然代码仍能正常工作，这得益于JavaScript是动态语言，它能自动帮你调用子类上的同名函数。但若能明确传达出“继承`Party`类的子类需要提供一个`monthlyCost`实现”这个信息，无疑也有很大的价值，特别是对日后需要添加子类的后来者。其中一种好的传达方式是添加一个如下的陷阱（trap）函数。 ##### class Party... ``` get monthlyCost() { throw new SubclassResponsibilityError(); } ``` 我称上述抛出的错误为一个“子类未履行职责错误”，这是从Smalltalk借鉴来的名字。