重新组织数据之八 :Change Bidirectional Association to Unidirectional(将双向关联改为单向)

两个鄉之间有双向关联,但其中一个class如今不再需要另一个class的特性。

去除不必要的关联(association)。

动机(Motivation)

双向关联(bidirectional associations)很有用,但你也必须为它付出代价,那就是「维护双向连接、确保对象被正确创建和删除」而增加的复杂度。而且,由于很多程序 员并不习惯使用双向关联,它往往成为错误之源。

大量的双向连接(two-way links)也很容易引发「僵尸对象」:某个对象本来已经该死亡了,却仍然保留在系统中,因为对它的各项引用还没有完全清除。

此外,双向关联也迫使两个classes之间有了相依性。对其中任一个class的任何修 改,都可能引发另一个class的变化。如果这两个classes处在不同的package中, 这种相依性就是packages之间的相依。过多的依存性(inter-dependencies)会造就紧耦合(highly coupled)系统,使得任何一点小小改动都可能造成许多无法预知的后果。

只有在你需要双向关联的时候,才应该使用它。如果你发现双向关联不再有存在价值,就应该去掉其中不必要的一条关联。

作法(Mechanics)

·找出『你想去除的指针」的保存值域,检查它的每一个用户,判断是否可以去除该指针。

Ø不但要检查「直接读取点」,也要检查「直接读取点」的调用函数。

Ø考虑有无可能不通过指针取得「被引用对象」(referred object)。如 果有可能,你就可以对取值函数(getter)使用Substitute Algorithm,从而让客户在没有指针的情况下也可以使用该取值函数。

Ø对于使用该值域的所有函数,考虑将「被引用对象」(refered object)作为引数(argument)传进去。

·如果客户使用了取值函数(getter),先运用Self Encapsulate Field 将「待除值域」自我封装起来,然后使用Substitute Algorithm 对付取值函数,令它不再使用该(待除)值域。然后编译、测试。

·如果客户并未使用取值函数(getter),那就直接修改「待除值域」的所有被引用点:改以其他途径获得该值域所保存的对象。每次修改后,编译并测试。

·如果已经没有任何函数使用该(待除〕值域,移除所有「对该值域的更新逻辑」,然后移除该值域。
Ø如果有许多地方对此值域赋值,先运用Self Encapsulate Field 使这些地点改用同一个设值函数(setter)。编译、测试。而后将这个 设值函数的本体清空。再编译、再测试。如果这些都可行,就可以将此值域和其设值函数,连同对设值函数的所有调用,全部移除。

·编译,测试。

范例(Example)

本例从 Change Unidirectional Association to Bidirectional 留下的代码开始进行,其中Customer和Order之间有双向关联:

class Order...

   Customer getCustomer() {

       return _customer;

   }

   void setCustomer (Customer arg) {

       if (_customer != null) _customer.friendOrders().remove(this);

       _customer = arg;

       if (_customer != null) _customer.friendOrders().add(this);

   }

   private Customer _customer;        //译注:这是Order-to-Customer link也是本例的移除对象

class Customer...

   void addOrder(Order arg) {

       arg.setCustomer(this);

   }

   private Set _orders = new HashSet();

       //译注:以上是Customer-to-Order link

   Set friendOrders() {

       /** should only be used by Order */

       return _orders;

   }

后来我发现,除非先有Customer对象,否则不会存在Order对象。因此我想将「从Order 到Customer的连接」移除掉。

对于本项重构来说,最困难的就是检查可行性。如果我知道本项重构是安全的,那么重构手法自身十分简单。问题在于是否有任何代码倚赖_customer 值域的存在。 如果确实有,那么在删除这个值域之后,我必须提供替代品。

首先,我需要研究所有读取这个值域的函数,以及所有使用这些函数的函数。我能找到另一条途径来供应Customer对象吗——这通常意味将Customer对象作为引数(argument)传递给其用户〔某函数〕。下面是一个简化例子:

class Order...

       double getDiscountedPrice() {

       return getGrossPrice() * (1 - _customer.getDiscount());

   }

改变为:

class Order...

   double getDiscountedPrice(Customer customer) {

       return getGrossPrice() * (1 - customer.getDiscount());

   }

如果待改函数是被Customer对象调用的,那么这样的修改方案特别容易实施,因为Customer对象将自己作为引数(argument)传给函数很是容易。所以下列代码:

class Customer...

   double getPriceFor(Order order) {

       Assert.isTrue(_orders.contains(order)); // see Introduce Assertion (267)

       return order.getDiscountedPrice();

变成了:

class Customer...

   double getPriceFor(Order order) {

       Assert.isTrue(_orders.contains(order));

       return order.getDiscountedPrice(this);

   }

另一种作法就是修改取值函数(getter),使其在不使用_customer 值域的前提下返回一个Customer对象。如果这行得通,我就可以使用Substitute Algorithm 修改Order.getCustomer()函数算法。我有可能这样修改代码:

   Customer getCustomer() {

       Iterator iter = Customer.getInstances().iterator();

       while (iter.hasNext()) {

           Customer each = (Customer)iter.next();

           if (each.containsOrder(this)) return each;

       }

       return null;

   }

这段代码比较慢,不过确实可行。而且,在数据库环境下,如果我需要使用数据库查询语句,这段代码对系统性能的影响可能并不显著。如果Order class中有些函 数使用_customer值域,我可以实施Self Encapsulate Field 令它们转而改 用上述的getCustomer() 函数。

如果我要保留上述的取值函数(getter),那么Order和Customer的关联从接口上看虽然仍是双向,但实现上已经是单向关系了。虽然我移除了反向指针,但两个classes彼此之间的依存关系(inter-dependencies)仍然存在。

如果我要替换取值函数(getter),那么我就专注地替换它,其他部分留待以后处理。 我会逐一修改取值函数的调用者,让它们通过其他来源取得Customer对象。每次修改后都编译并测试。实际工作中这一过程往往相当快。如果这个过程让我觉得很棘手很复杂,我会放弃本项重构。

一旦我消除了_customer值域的所有读取点,我就可以着手处理「对此值域进行赋值动作」的函数了(译注:亦即设值函数,setter)。很简单,只要把这些赋值动作 全部移除,再把值域一并删除,就行了。由于已经没有任何代码需要这个值域,所以删掉它并不会带来任何影响。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值