|
#
- 作法（Mechanics)
- 声明一个常量,令其值为原本的魔法数值.
- 找出这个魔法数的所有引用点.
- 检查是否可以使用这个新声明的常量来替换该魔法数.如果可以,便以一常量替换之.
- 编译.
- 所有魔法数都被替换完毕后,编译并测试.此时整个程序应该运转如常,就像没有做任何修改一样.
- ==>有个不错的测试办法:检查现在的程序是否可以被你轻松地修改常量值(这可能意味某些预期结果将有所改变,以配合这一新值.实际工作中并非总是可以进行这样的测试).如果可行,这就是一个不错的手法.
动机（Motivation）
在计算科学中,魔法数(magic number)是历史最悠久的不良现象之一.
进行本项重构之前,你应该先寻找其他替换方案.你应该观察魔法数如何被使用,而后往往你会发现一种更好的使用方式.如果这个魔法数是个type code(型别码),请考虑使用Replace Type Code with Class(218);如果这个魔法数代表一个数组的长度,请在遍历该数组的时候,改用Array.length().
你有一个字面数值(literal number),带有特殊含义. 创造一个常量,根据其意义为它命名,并将上述的字面数值替换为这个常量.
double potentialEnergy(double mass, double height) {
return mass * 9.81 * height;
}
double potentialEnergy(double mass, double height) {
return mass * GRAVITATIONAL_CONSTANT * height;
}
static final double GRAVITATIONAL_CONSTANT = 9.81;
范例（Examples）
本例从Change Unidirectional association to Bidirectional(197)留下的代码开始进行,其中Customer和Order之间有双向关联:
class Order...
Customer getCustomer() {
return _customer;
}
void setCustomer(Custoemr 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() {
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(139)修改Order.getCustomer()函数算法.我有可能这样修改代码:
Customer getCustomer() {
Iterator iter = Customer.getInstance().iterator();
while(iter.hasNext()) {
Customer each = (Customer)iter.next();
if(each.containsOrder(this) return each;
}
return null;
}
这段代码比较慢,不过确实可行.而且,在数据库环境下,如果我需要使用数据库查询语句,这段代码对系统性能的影响可能并不显著.如果,Order class中有些函数使用_customer值域,我可以实施Self Encapsulate Field(171)令它们转而改用上述的getCustomer()函数.
如果我要保留上述的取值函数(getter),那么Order和Customer的关联从接口上看虽然仍然是双向,但实现上已经是单向关系了.虽然我移除了反向指针,但两个classes彼此之间的依存关系(inter-dependencies)仍然存在.
如果我要替换取值函数(getter),那么我就专注地替换它,其他部分留待以后处理.我会逐一修改取值函数的调用者.让它们通过其他来源取得Customer对象.每次修改后都编译并测试.实际工作中这一过程往往相当快.如果这个过程让我觉得很棘手很复杂,我会放弃本项重构.
一旦我消除了_customer值域的所有读取点,我就可以着手处理[对此值域进行赋值动作]的函数了.很简单,只要把这些赋值动作全部移除,再把值域一并删除,就行了.由于已经没有任何代码需要这个值域,所以删掉它并不会带来任何影响.
- 作法（Mechanics)
- 找出[你想去除的指针]的保存值域,检查它的每一个用户,判断是否可以去除该指针.
- ==>不但要检查[直接读取点],也要检查[直接读取点]的调用函数.
- ==>考虑有无可能不通过指针函数取得[被引用对象](referred object).如果有可能,你就可以对取值函数(getter)使用Substitute Algorithm(139).从而让客户在没有指针的情况下也可以使用该取值函数.
- ==>对于使用该值域的所有函数,考虑将[被引用对象](referred object)作为引数(argument)传进去.
- 如果客户使用了取值函数(getter),先运用Self Encapsulate Field(171)将[待除值域]自我封装起来,然后使用Subsitute Algorithm(139)对付取值函数,令它不再使用该(待除)值域.然后编译,测试.
- 如果客户并使用取值函数(getter),那就直接修改[待除值域]的所有被引用点:改以其他途径获得该值域所保存的对象.每次修改后,编译并测试.
- 如果已经没有任何函数使用该(待除)值域,移除所有[对该值域的更新逻辑],然后移除该值域.
- ==>如果有许多地方对此值域赋值,先运用Self Encapsulate Field(171)使这些地点改用同一个设值函数(setter).编译,测试.而后将这个设值函数的本体清空.再编译,再测试.如果这些都可行,就可以将此值域和其设值函数,连同对设值函数的所有调用,全部移除.
- 编译,测试.
动机（Motivation）
双向关联(bidirectional associations)很有用,但你也必须为它付出代价,那就是[维护双向链接,确保对象被正确创建和删除]而增加的复杂度.而且,由于很多程序员并不习惯使用双向关联,它往往成为错误之源.
大量的双向连接(two-way links)也很容易引发[僵尸对象]:某个对象本来已经该死亡了,却仍然保留在系统中,因为对它的各项引用还没有完全清除.
此外,双向关联也迫使两个classes之间有了相依性.对其中任一个class的任何修改,都可能引发另一个class的变化.如果这两个classes处在不同的package中,这种相依性就是packages之间的相依.过多的依存性(inter-dependencies)会造成就紧耦合(highly coupled)系统,使得任何一点小小改动都可能造成许多无法预知的后果.
只有在你需要双向关联的时候,才应该使用它.如果你发现双向关联不再有存在价值,就应该去掉其中不必要的一条关联.
两个classes之间有双向关联,但其中一个class如今不再需要另一个class的特性. 去除不必要的关联(association).
范例（Examples）
下面是一段简单程序，其中有两个classes：表示[定单]的 Order和表示[客户]的 Customer。 Order引用了 Customer， Customer则并没有引用 Order：
class Order...
Customer getCustomer() {
return _customer;
}
void setCustomer(Customer arg) {
_Customer = arg;
}
Customer _customer; //这是一个“Order”to “Customer”的连接
首先，我要为 Customer添加一个值域。由于一个客户可以拥有多份定单，所以这个新增值域应该是个群集（collection）。我不希望同一份定单在同一个群集中出现一次以上，所以这里适合使用set：
class Customer {
private Set _orders = new HashSet();
现在，我需要决定由哪一个class负责控制关联性（association）。我比较喜欢让单一class来操控，因为这样我就可以将所有[关联处理逻辑]集中安置于一地。我将按照下列步骤做出这一决定：
- 如果两者都是reference objects，而其间的关联是[一对多]关系，那么就由[拥有单一reference]的那一方承担[控制者]角色。以本例而言，如果一个客户可拥有多份定单，那么就由Order class(定单)来控制关联性。
- 如果某个对象是另一个对象的组成（component），那么由后者负责控制关联性。
- 如果两者都是reference objects，而其间的关联是[多对多]关系，那么随便其中哪个对象来控制关联性，都无所谓。
本例之中由于Order负责控制关联性，所以我必须为Customer添加一个赋值函数，让Order可以直接访问_orders（订单）集群。 Order的修改函数（modifier）将使用这个辅助函数对指针两端对象进行同步控制。我将这个赋值函数命名为friendOrders（），表示这个函数只能在这种特殊情况下使用。此外，如果 Order和 Customer位在同一个 package内，我还会将friendOrders（）声明为[package 可见度]，使其可见程度降至最低。
但如果这两个classes不在同一个package内，我就只好把friendOrders（）声明为 public了。
class Customer...
Set friendOrders() {
return _orders;
}
现在。我要改变修改函数（modifier），令它同时更新反向指针：
class Order...
void setCustomer(Custoemr 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);
}
- 作法（Mechanics)
- 在referred class中增加一个值域,用以保存[反向指针].
- 决定由哪个class(引用端或被引用端)控制关联性(association).
- 在[被控制]建立一个辅助函数,其命名应该清楚指出它的有限用途.
- 如果既有的修改函数(modifier)在[控制端],让它负责更新反向指针.
- 如果既有的修改函数(modifier)在[控制端]
开发初期,你可能会在两个classes之间建立一条单向连接,使其中一个class可以引用另一个class.随着时间推移,你可能发现referred class需要得到其引用者(某个object)以便进行某些处理.也就是说它需要一个反向指针.
[反向指针]手法有点棘手,所以在你能够自在运用它之前,应该有相应的测试.通常我不花心思去测试访问函数(accessors),因为普通访问函数的风险没有高到需要测试的地步,但本重构要求测试访问函数,所以它是极少数需要添加测试的重构手法之一.
本重构运用反向指针(back pointer)实现双向关联(bidirectionality).其他技术(例如连接对象,link objects)需要其他重构手法.
|