按合同库（界面）设计的想法？

Question

我正在研究一个 Java 库的契约设计，这是我迄今为止在界面方面提出的想法。

用户可以调用executeContract，并且executeContract在调用'require'之后调用invokeContract。 Ensure 在executeContract 之后调用，以确保invokeContract 返回内容的正确性。

此代码也可用作回调方法（匿名内部类调用）。

你怎么看？ 这是按合同设计的吗？到目前为止，这有助于我编写可测试的 Java 代码。

public interface IContractHandler {

    /**
     * Execute contract will invoke the #invokeContract method.  In the execute method, 
     * check for the validity of the preconditions and the post conditions.
     * 
     * The precondition can be null.
     * 
     * @param    precondInput -  Precondition Input Data, can be null.
     * @return                   Post condition output
     */
    public Object executeContract(final Object precondInput) throws ContractError;

    /**
     * Require that the preconditions are met.
     */
    public Object require(final Object precondInput) throws ContractError;

    /**
     * Ensure that the postconditions are met.
     */
    public Object ensure(final Object precondInput) throws ContractError;

    /**
     * The precondition can be null if the contract allows for that.
     * 
     * @param    precondInput -  Precondition Input Data, can be null.
     * @return                   Post condition output
     */
    public Object invokeContract(final Object precondInput) throws ContractError;

}

Answer 1

您如何知道实现此方法的人会遵守您的 executeContract 规则（即它在调用 require 之后调用 invokeContract）？ 答案 - 你不知道。

最好在抽象类中包含 executeContract ，以便您可以强制执行该行为，如果您确实不希望人们改变该行为，则可以将其定为最终的。

如果invokeContract和require只需要被executeContract调用，那么就不需要将它们公开。

我很惊讶 require 和 ensure 返回 Object，因为它们听起来像是只返回 boolean 的方法>。 事实上，除非确实需要，否则返回Object通常不好。 现在的情况是，实现此功能的类的使用者可以获取任何内容，并且不想到处进行 instanceof 检查。

一切真的都需要抛出ContractError吗？

希望这可以帮助。

Answer 2

如果您正在寻找通用解决方案，我会推荐 < em>Java 建模语言。 所有前置/后置条件 (@requires/@ensures) 都可以在您要检查的方法上方的注释中指定。 据我了解，JML 编译器 (jmlc) 将运行时断言插入字节码中。

我相信 ESC/Java2 具有类似的功能，但我以前从未使用过它。

Answer 3

实际上，在这种情况下您要寻找的是一种称为 模板方法 的模式。 接口并不决定实现，这正是您在executeContract() 方法中尝试执行的操作。