诊断Java代码: Broken Dispatch错误情势[Java编程]

整体和部份

还记得这条谚语吗,“整体大于部份之和”?假如把一个个独立的事件组合成一个彼此作用的整体,产生的后果会比单个个体的作用之和要大得多.

程序也是一样的原理.随着一个个新办法被增添到程序中,整个程序大概的掌握流程疾速增添.关于大型程序而言,很快局面就会无法掌握了.就象是一个荒诞而又难以想象的戏法,有时您得到的终究后果并非您所盼望的方向 ― 这同您在重载办法大概覆盖办法时碰到的情形有些近似.

Broken Dispatch 错误情势

面向对象语言的最强盛的特点之一就是担当多态性.这一特点答应我们按照参数范例重载和覆盖办法.但是,象别的功效强盛的工具一样,这个特点也会引入新的危险.

固然 Java 程序员们很快就可以学会管理一次调用中将调用哪个办法的法则,但在大型程序中却很简单呈现这种情形:在一个类中重载了一个办法,后果倒是从前在另一个类中可以运行的代码被中止了.这样的错误正符合我所说的 Broken Dispatch 情势.

该情势可以描写以下:

传送给某个重载办法,比方 foo 的参数,却被传给了另一个办法,比方 goo ,它支持更遍及的参数范例.

goo 然后通过这些参数调用 foo .

但是由于 goo 内的这些参数的静态范例更为遍及,因此,大概会调用办法 foo 的错误版本.

象这样的错误很难诊断,因为大概只是增添了新的办法（而不是改正现有的办法）就引入了错误.并且,在发现问题之前,程序大概会持续履行相当长的一段时间.

症状

为了阐明这种情势的本质,让我们来看看下面这段示例代码,它是为实现我前面的文章“ 空标志错误情势”中的不可变列表而编写的.

清单 1. 实现不可变列表

interface List {
　 public Object getFirst();
　 public List getRest();
}
class Empty implements List {
　 public Object getFirst() { throw new NoSuchElementException(); }
　 public List getRest() { throw new NoSuchElementException(); }
　 public boolean equals(Object that) {
　　 return this.getClass() == that.getClass();
　 }
}
class Cons implements List {
　
　 Object first;
　 List rest;
　
　 Cons(Object _first) {
　　 this.first = _first;
　　 this.rest = new Empty();
　 }
　 Cons(Object _first, List _rest) {
　　 this.first = _first;
　　 this.rest = _rest;
　 }
　 public Object getFirst() { return this.first; }
　 public List getRest() { return this.rest; }
　 ...
}

　　以上是“诊断Java代码: Broken Dispatch错误情势[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：