### Change Unidirectional Association to Bidirectional(将单向关联改为双向)
两个classes都需要使用对方特性,但其间只有一条单向连接(one-way link)。
添加一个反向指针,并使修改函数(modifiers)能够同时更新两条连接。(译注:这里的指针等同于句柄(handle),修改函数(modifier)指的是改变双方关系者)
![](https://box.kancloud.cn/2016-08-15_57b1b56d46496.gif)
**动机(Motivation)**
开发初期,你可能会在两个classes之间建立一条单向连接,使其中一个可以引用另一个class。随着时间推移,你可能发现referred class 需要得到其引用者(某个object)以便进行某些处理。也就是说它需要一个反向指针。但指针乃是一种单向连接,你不可能反向操作它。通常你可以绕道而行,虽然会耗费一些计算时间, 成本还算合理,然后你可以在referred class中建立一个专职函数,负责此一行为。 但是,有时候,想绕过这个问题并不容易,此时你就需要建立双向引用关系(two-way reference),或称为反向指针(back pointer)。如果你不习惯使用反向指针,它们很容易造成混乱;但只要你习惯了这种手法,它们其实并不是太复杂。
「反向指针」手法有点棘手,所以在你能够自在运用它之前,应该有相应的测试。通常我不花心思去测试访问函数(accessors),因为普通访问函数的风险没有高到需要测试的地步,但本重构要求测试访问函数,所以它是极少数需要添加测试的重构 手法之一。
本重构运用反向指针(back pointer)实现双向关联(bidirectionality)。其他技术(例如连接对象,link object)需要其他重构手法。
**作法(Mechanics)**
- 在class中增加一个值域,用以保存「反向指针」。
- 决定由哪个class (引用端或被引用端)控制关联性(association)。
- 在「被控端」建立一个辅助函数,其命名应该清楚指出它的有限用途。
- 如果既有的修改函数(modifier)在「控制端」,让它负责更新反向指针。
- 如果既有的修改函数(modifier)在「被控端」,就在「控制端」建立一个控制函数,并让既有的修改函数调用这个新建的控制函数。
**范例(Example)**
下面是一段简单程序,其中有两个classes:表示「定单」的Order 和表示「客户」的Customer。Order引用了Customer,Customer则并没有引用Order:
~~~
class Order...
Customer getCustomer() {
return _customer;
}
void setCustomer (Customer arg) {
_customer = arg;
}
Customer _customer;
~~~
首先,我要为Customer添加一个值域。由于一个客户可以拥有多份定单,所以这个新增值域应该是个群集(collection)。我不希望同一份定单在同一个群集中出现一次以上,所以这里适合使用set:
~~~
class Customer {
private Set _orders = new HashSet();
~~~
现在,我需要决定由哪一个class负责控制关联性(association)。我比较喜欢让单一class来操控,因为这样我就可以将所有「关联处理逻辑」集中安置于一地。我将按照下列步骤做出这一决定:
1.
如果两者都是reference objects,而其间的关联是「一对多」关系,那么就由「拥有单一 reference 」的那一方承担「控制者」角色。以本例而言,如果一个客户可拥有多份定单,那么就由Order class (定单)来控制关联性。
1.
如果某个对象是另一对象的组成(component),那么由后者负责控制关联性。
1.
如果两者都是reference objects,而其间的关联是「多对多」关系,那么随便其中哪个对象来控制关联性,都无所谓。
本例之中由于Order负责控制关联性,所以我必须为Customer添加一个辅助函数,让Order可以直接访问 _orders(订单〕群集。Order的修改函数(modifier)将使用这个辅助函数对指针两端对象进行同步控制。我将这个辅助函数命名为friendOrders() ,表示这个函数只能在这种特殊情况下使用。此外,如果Order和Customer位在同一个package内,我还会将friendOrders ()声明为「package可见度」(译注:亦即不加任何修饰符的缺省访问级别),使其可见程度降到最低。
但如果这两个classes不在同一个package内,我就只好把friendOrders() 声明为public 了。
~~~
class Customer...
Set friendOrders() {
/** should only be used by Order when modifying the association */
return _orders;
}
~~~
现在,我要改变修改函数(modifier),令它同时更新反向指针:
~~~
class Order...
void setCustomer (Customer arg) ...
if (_customer != null) _customer.friendOrders().remove(this);
_customer = arg;
if (_customer != null) _customer.friendOrders().add(this);
}
~~~
classes 之间的关联性是各式各样的,因此修改函数(modifier )的代码也会随之有所差异。如果_customer 的值不可能是null ,我可以拿掉上述的第一个null 检查, 但仍然需要检查引数(argument)是否为null 。不过,基本形式总是相同的:先让对方删除「指向你」的指针,再将你的指针指向一个新对象,最后让那个新对象把 它的指针指向你。
如果你希望在Customer 中也能修改连接(link),就让它调用控制函数:
~~~
class Customer...
void addOrder(Order arg) {
arg.setCustomer(this);
}
~~~
如果一份定单也可以对应多个客户,那么你所面临的就是一个「多对多」情况,重构后的函数可能是下面这样:
~~~
class Order... //controlling methods
void addCustomer (Customer arg) {
arg.friendOrders().add(this);
_customers.add(arg);
}
void removeCustomer (Customer arg) {
arg.friendOrders().remove(this);
_customers.remove(arg);
}
class Customer...
void addOrder(Order arg) {
arg.addCustomer(this);
}
void removeOrder(Order arg) {
arg.removeCustomer(this);
}
~~~
- 译序 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 )
- 小结
- 章节十五 集成
- 参考书目