### 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)。很简单，只要把这些赋值动作 全部移除，再把值域一并删除，就行了。由于已经没有任何代码需要这个值域，所以删掉它并不会带来任何影响。