<b>诊断Java代码: 臆想实现错误情势,第2部份</b>[Java编程]

臆想实现重温

回想一下 上次接口的 臆想实现是一个合理的实现,但不满意接口标准的某些未经查抄的方面.我们考虑一下下面的仓库接口,以及很多未被其单独的范例签名捕捉的不变量:

清单 1. 一个仓库接

public interface Stack {
　 public Object pop();
　 public void push(Object top);
　 public boolean isEmpty();
}

比方,请考虑我们但愿肆意仓库实现都服从的下列法则:

假如一个对象 o 被压进仓库 s ,且在仓库上履行的下一个操作是 pop ,则该操作的返回值将为 o .

关于一个给定的仓库 s ,假如 s.isEmpty() 的返回值为 true ,且在仓库上履行的下一个操作是 pop ,那么对 pop 的调用将抛出一个 RuntimeException 非常.

固然 Java 语言在接口不变量的标准方面有限制,但指定象这样的增添的接口不变量还是大概的.就象我们将看到的那样,您可以用这种可以自动查抄以查看接口实现能否满意它们的办法来指定这些不变量.

断言

向程序中增添 断言是一个很老但未被充分操纵的好主张.这种思惟是在程序履行的差别阶段置入某些条件的布尔查抄.按照 design by contract思惟,断言应当被包含在接口实现与外部客户达成的协议中.普通情形下,断言利用下面 3 种改变情势之一:

前提条件查抄在进入代码块之前某些条件能否成立.

后置条件查抄在退出代码块时某些条件能否成立.

不变量查抄在代码块履行 期间能否具有某些条件.由于它们的代价问题,这类断言极少以其最通例的情势受支持.相反,答应程序员查抄代码块履行的某个 点能否具有各种条件.

关于不给定实现代码的接口标准,前两种是最有效的.

引入了基于 Java 的预处理器,如 iContract 之后,就有大概将断言放入源代码中并使它们自动转换为举行查抄以确保断言永久有效的 Java 代码.由于经这些工具处理过的断言在原始文件中被指定为 Javadoc 注释,我们便可以很简单地编译该文件,而无须运行预处理器,为未查抄任何断言的代码制作一个“产品”副本.但用这种办法除去断言太过频繁.除对性能影响至关重要的部份之外,在程序的别的全部部份,断言查抄的系统开销都不会很大.将断言留在程序中,可以使得诊断来自终究用户的错误报告越发简单（必定 将会有错误报告）.

在我们的仓库示例中,我们可以向 pop pop 增添一个断言,以确保 pop 永久不会在空仓库上被调用:

清单 2. 测试仓库接口的一个断言

public interface Stack {
　 /**
　 *@pre ! this.isEmpty()
　 */
　 public Object pop();
　 public void push(Object top);
　 public boolean isEmpty();
}

向接口代码中增添近似这样的断言有助于确保当调用实现办法时,这种附加的不变量有效.因为它们可被编译成代码,所以它们是快速诊断臆想实现发生的高效办法.并且,它们还可作为接口的附加文档.但是,由于它们是严峻的函数布尔表达式,它们被限制在自己的表达中 ― 比方,我们将若何把仓库的第一条法则编写到断言中?与范例声明相同,断言自身表达本领不够,无法捕捉我们大概但愿在接口上指定的全部法则.由于这个缘由,最好是将它们与单元测试合力利用.

　　以上是“<b>诊断Java代码: 臆想实现错误情势,第2部份</b>[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：