Дизайн по контракту библиотека (интерфейс) мысли?

Question

Я смотрю на проектирование по контракту для библиотеки Java, это то, что я до сих пор придумал с точки зрения интерфейса.

Пользователь может вызвать executeContract, а executeContract вызывает invokeContract после вызова 'require'. гарантированно вызывается после 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

Если вы ищете универсальное решение для этого, я бы порекомендовал Язык моделирования Java . Все предварительные / постусловия (@requires/@ensures) могут быть указаны в аннотациях над методом, который вы хотите проверить. Насколько я понимаю, JML-компилятор (jmlc) вставляет утверждения времени выполнения в байт-код.

Полагаю, ESC / Java2 обладает аналогичным типом функциональности, но я никогда не использовал его раньше.

Answer 2

Откуда вы знаете, что люди, реализующие этот метод, будут подчиняться вашим правилам для executeContract (то есть, что он вызывает invokeContract после вызова требуют )? Ответ - нет.

Лучше иметь executeContract в абстрактном классе, чтобы вы могли применять это поведение, возможно, сделав его окончательным, если вы действительно не хотите, чтобы люди изменяли это поведение.

Если invokeContract и требуют, чтобы вызывался только с помощью executeContract , то нет необходимости делать их общедоступными.

Я удивлен, что требуют и , гарантируют возврат Объект , поскольку они звучат как методы, которые просто возвращали бы логическое значение, На самом деле, возвращение Object - это то, что, как правило, не очень хорошо, если только вам это не нужно. В настоящее время потребитель класса, реализующего это, может получить что-нибудь обратно и не хочет делать instanceof проверок повсеместно.

Действительно ли все нужно выбросить ContractError ?

Надеюсь, это поможет.

Answer 3

На самом деле, в этой ситуации вы ищете шаблон, называемый Template Method . Интерфейсы не определяют реализацию, что вы пытаетесь сделать в вашем методе executeContract ().