Использование обратного вызова вместо возврата объекта состояния

Question

В моем приложении я выполнения транзакции, которая может находиться в трех различных состояниях в конце исполнения:

• Успех
• Failure
• В ожидании

В зависимости от состояния клиент приложения будет выполнять различные действия. В случае успеха они захотят получить результат транзакции (виджет). В случае сбоя они захотят получить причину ошибки. В случае ожидания транзакции они захотят запланировать время для повторной попытки. В настоящее время я возвращаю объект со следующими методами:

public interface Result() { 
    State getState(); 
    Widget getWidget(); // Success 
    Reason getFailureReason(); // Failure 
    Callable<Result> getTask(); // Pending 
} 

Идея заключается в том, что клиент проверяет состояние объекта результата, и вызывает соответствующий метод в зависимости от его значения, например,

if (result.getState() == State.PENDING) { 
    result.getTask(); 
} 

Я думал, что предпочтительнее использовать обратный вызов, например,

public interface TransactionCallback() { 
    void onFailure(Reason reason); 
    void onSuccess(Widget widget); 
    Delay onPending(Delay previous); 
} 

Где Delay это класс, представляющий TimeUnit и период, что позволяет приложению перенести выполнение транзакции. Другой альтернативой является бросить исключение, обертывающее причину сбоя (поскольку оно должно только терпеть неудачу в исключительных условиях), и сохраняйте методы onSuccess10 и onPending.

Итак, мой вопрос к SO: это использование обратного вызова соответствующего шаблона для этой конкретной проблемы, или кто-нибудь может предложить что-то более подходящее?

Answer 1

Я не думаю, что это хороший подход к обратному шаблону.

Обратный вызов подходит, если вызов (например, транзакция в вашем случае) должен продолжать выполнять действия после возврата метода обратного вызова. Но если следующая вещь, которую всегда вызывает вызываемый, - это возврат к вызывающему, тогда обратный вызов не добавляет никакого значения. Это просто делает структуру кода более сложной и менее читаемой.ИМО, было бы лучше вернуть объект результата или (в случае исключительного отказа) вызвать исключение.

EDIT - комментарий Комитета.

Я могу увидеть значение метода обратного вызова, чтобы спросить вызывающего, если транзакция должна продолжаться, хотя я, вероятно, использовал бы простой параметр таймаута. Однако использование методов обратного вызова для возврата результатов (IMO) по-прежнему не так.

Answer 2

Я предпочитаю обратные вызовы, так как если вы используете его в нескольких местах, это приведет к уменьшению количества кода и станет более читаемым. С вызовом вашего оператора if, чтобы определить, что произойдет (какой метод для вызова) будет находиться в сервисе, выполняющем транзакцию, и весь код, использующий эту услугу, будет выглядеть только чище.

Answer 3

Аргументы обратного вызова должны включать объект, запрашивающий вызов. Звучит отлично для меня, но использование обратного вызова может включать в себя некоторые проблемы синхронизации - вы не можете быть уверены, в каком состоянии вы получите обратный вызов. Не невозможно, но может потребоваться рассмотрение.

Конечно, при опросе результата вам потребуется синхронизация с другой стороны. Но это звучит проще для синхронизации.

Answer 4

Решение обратного вызова много расширяемо, хотя вы можете в какой-то момент изменить поведение на асинхронный вызов.

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