### Replace Delegation with Inheritance(以继承取代委托)
你在两个classes 之间使用委托关系(delegation),并经常为整个接口编写许多极简单的请托函数(delegating methods)。
让「请托(delegating)class」继承「受托 class (delegate)」。
![](https://box.kancloud.cn/2016-08-15_57b1b5e7d248f.gif)
**动机(Motivation)**
本重构与 Replace Delegation with Inheritance 恰恰相反。如果你发现自己需要使用「受托 class」中的所有函数,并且费了很大力气编写所有极简的请托函数(delegating methods),本重构可以帮助你轻松回头使用「继承」。
两条告诫需牢记于心。首先,如果你并没有使用「受托class 」的所有函数(而非只是部分函数),那么就不应该使用Replace Delegation with Inheritance,因为subclass 应该总是遵循(奉行)superclass 的接口。如果过多的请托函数让你烦心,你有别的选择:你可以通过 Remove Middle Man 让客户端自己调用受托函数,也可以使用Extract Superclass 将两个classes 接口相同的部分提炼到superclass 中, 然后让两个classes 都继承这个新的superclass ;你还可以以类似手法使用Extract Interface。
另一种需要当心的情况是:受托对象被不止一个其他对象共享,而且受托对象是可变的(mutable)。在这种情况下,你就不能将「委托关系」替换为「继承关系」,因为这样就无法再共享数据了。数据共享是必须由「委托关系」承担的一种责任,你无法把它转给「继承关系」。如果受托对象是不可变的(immutable),数据共享就不 成问题,因为你大可放心地拷贝对象,谁都不会知道。
**作法(Mechanics)**
- 让「请托端」成为「受托端」的一个subclass 。
- 编译。
- 此时,某些函数可能会发生冲突:它们可能有相同的名称,但在返回型别(return type)、异常指定(exceptions)或可视性(visibility)方面有所差异。你可以使用Rename Method 解决此类问题。
- 将「受托值域」(delegated field)设为「该值域所处之对象自身」。
- 去掉简单的请托函数(delegating methods)。
- 编译并测试。
- 将所有其他「涉及委托关系」的动作,改为「调用对象自身(继承而来的函 数)」。
- 移除「受托值域」(delegated field)。
**范例:(Example)**
下面是一个简单的Employee,将一些函数委托给另一个同样简单的Person :
~~~
class Employee {
Person _person = new Person();
public String getName() {
return _person.getName();
}
public void setName(String arg) {
_person.setName(arg);
}
public String toString () {
return "Emp: " + _person.getLastName();
}
}
class Person {
String _name;
public String getName() {
return _name;
}
public void setName(String arg) {
_name = arg;
}
public String getLastName() {
return _name.substring(_name.lastIndexOf(' ')+1);
}
}
~~~
第一步,只需声明两者之间的继承关系:
~~~
class Employee extends Person
~~~
此时,如果有任何函数发生冲突,编译器会提醒我。如果某几个函数的名称相同、但返回型别不同,或抛出不同的异常,它们之间就会出现冲突。所有此类问题都可以通过Rename Method 加以解决。为求简化,我没有在范例中列出这些麻烦情况。
下一步要将「受托值域」(delegated field)设值为「该值域所处之对象自身」。同时,我必须先删掉所有简单的请托函数(例如getName() 和setName())。如果留下这种函数,就会因为无限递归而引起系统的call stack 满溢(overflow)。在此范例中,我应该把Employee 的getName() 和setName() 拿掉。
一旦Employee 可以正常工作了,我就修改其中「使用了请托函数(译注:或受托值域)」的函数,让它们直接调用「从superclass 继承而来的函数」:
~~~
public String toString () {
return "Emp: " + getLastName();
}
~~~
摆脱所有涉及委托关系的函数后,我也就可以摆脱_person 这个(受托)值域了。
- 译序 by 侯捷
- 译序 by 熊节
- 序言
- 前言
- 章节一 重构,第一个案例
- 起点
- 重构的第一步
- 分解并重组statement()
- 运用多态(Polymorphism)取代与价格相关的条件逻辑
- 结语
- 章节二 重构原则
- 何谓重构
- 为何重构
- 「重构」助你找到臭虫(bugs)
- 何时重构
- 怎么对经理说?
- 重构的难题
- 重构与设计
- 重构与性能(Performance)
- 重构起源何处?
- 章节三 代码的坏味道
- Duplicated Code(重复的代码)
- Long Method(过长函数)
- Large Class(过大类)
- Long Parameter List(过长参数列)
- Divergent Change(发散式变化)
- Shotgun Surgery(散弹式修改)
- Feature Envy(依恋情结)
- Data Clumps(数据泥团)
- Primitive Obsession(基本型别偏执)
- Switch Statements(switch惊悚现身)
- Parallel Inheritance Hierarchies(平行继承体系)
- Lazy Class(冗赘类)
- Speculative Generality(夸夸其谈未来性)
- Temporary Field(令人迷惑的暂时值域)
- Message Chains(过度耦合的消息链)
- Middle Man(中间转手人)
- Inappropriate Intimacy(狎昵关系)
- Alternative Classes with Different Interfaces(异曲同工的类)
- Incomplete Library Class(不完美的程序库类)
- Data Class(纯稚的数据类)
- Refused Bequest(被拒绝的遗贈)
- Comments(过多的注释)
- 章节四 构筑测试体系
- 自我测试代码的价值
- JUnit测试框架
- 添加更多测试
- 章节五 重构名录
- 重构的记录格式
- 寻找引用点
- 这些重构准则有多成熟
- 章节六 重新组织你的函数
- Extract Method(提炼函数)
- Inline Method(将函数内联化)
- Inline Temp(将临时变量内联化)
- Replace Temp with Query(以查询取代临时变量)
- Introduce Explaining Variable(引入解释性变量)
- Split Temporary Variable(剖解临时变量)
- Remove Assignments to Parameters(移除对参数的赋值动作)
- Replace Method with Method Object(以函数对象取代函数)
- Substitute Algorithm(替换你的算法)
- 章节七 在对象之间搬移特性
- Move Method(搬移函数)
- Move Field(搬移值域)
- Extract Class(提炼类)
- Inline Class(将类内联化)
- Hide Delegate(隐藏「委托关系」)
- Remove Middle Man(移除中间人)
- Introduce Foreign Method(引入外加函数)
- Introduce Local Extension(引入本地扩展)
- 章节八 重新组织数据
- Self Encapsulate Field(自封装值域)
- Replace Data Value with Object(以对象取代数据值)
- Change Value to Reference(将实值对象改为引用对象)
- Replace Array with Object(以对象取代数组)
- Replace Array with Object(以对象取代数组)
- Duplicate Observed Data(复制「被监视数据」)
- Change Unidirectional Association to Bidirectional(将单向关联改为双向)
- Change Bidirectional Association to Unidirectional(将双向关联改为单向)
- Replace Magic Number with Symbolic Constant(以符号常量/字面常量取代魔法数)
- Encapsulate Field(封装值域)
- Encapsulate Collection(封装群集)
- Replace Record with Data Class(以数据类取代记录)
- Replace Type Code with Class(以类取代型别码)
- Replace Type Code with Subclasses(以子类取代型别码)
- Replace Type Code with State/Strategy(以State/strategy 取代型别码)
- Replace Subclass with Fields(以值域取代子类)
- 章节九 简化条件表达式
- Decompose Conditional(分解条件式)
- Consolidate Conditional Expression(合并条件式)
- Consolidate Duplicate Conditional Fragments(合并重复的条件片段)
- Remove Control Flag(移除控制标记)
- Replace Nested Conditional with Guard Clauses(以卫语句取代嵌套条件式)
- Replace Conditional with Polymorphism(以多态取代条件式)
- Introduce Null Object(引入Null 对象)
- Introduce Assertion(引入断言)
- 章节十一 处理概括关系
- Pull Up Field(值域上移)
- Pull Up Method(函数上移)
- Pull Up Constructor Body(构造函数本体上移)
- Push Down Method(函数下移)
- Push Down Field(值域下移)
- Extract Subclass(提炼子类)
- Extract Superclass(提炼超类)
- Extract Interface(提炼接口)
- Collapse Hierarchy(折叠继承关系)
- Form Template Method(塑造模板函数)
- Replace Inheritance with Delegation(以委托取代继承)
- Replace Delegation with Inheritance(以继承取代委托)
- 章节十二 大型重构
- 这场游戏的本质
- Tease Apart Inheritance(梳理并分解继承体系)
- Convert Procedural Design to Objects(将过程化设计转化为对象设计)
- Separate Domain from Presentation(将领域和表述/显示分离)
- Extract Hierarchy(提炼继承体系)
- 章节十三 重构,复用与现实
- 现实的检验
- 为什么开发者不愿意重构他们的程序?
- 现实的检验(再论)
- 重构的资源和参考资料
- 从重构联想到软件复用和技术传播
- 结语
- 参考文献
- 章节十四 重构工具
- 使用工具进行重构
- 重构工具的技术标准(Technical Criteria )
- 重构工具的实用标准(Practical Criteria )
- 小结
- 章节十五 集成
- 参考书目