使用回调而不是返回状态对象

Question

在我的应用程序中，我正在执行一个在执行结束时可能处于三种不同状态的事务：

• 成功
• 失败
• 待处理

根据状态，应用程序客户端将希望执行不同的操作。在成功的情况下，他们会想要检索交易结果（一个Widget）。在失败的情况下，他们将希望收到错误原因。在事务未决的情况下，他们将希望安排时间重试。目前我使用以下方法返回一个对象：

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 和句点的类，允许应用程序重新安排事务执行。另一种选择是抛出一个包含失败原因的异常（因为它应该只在异常情况下失败），并保留onSuccess 和onPending 方法。

所以我对 SO 的问题是：对于这个特定问题，使用回调是一种合适的模式吗，或者任何人都可以提出更合适的建议吗？

Answer 1

我认为这不是回调模式的好用处。

如果被调用者（例如您的事务）需要在回调方法返回后继续执行操作，则回调是合适的。但是如果被调用者总是做的下一件事是返回给调用者，那么回调不会添加任何值。它只是使代码结构更复杂，可读性更差。 IMO，最好返回结果对象或（在异常失败的情况下）抛出异常。

EDIT - 回复 OP 的评论。

我可以看到使用回调方法询问调用者事务是否应该继续的价值，尽管我可能会使用一个简单的超时参数。但是，使用回调方法返回结果（IMO）仍然是错误的。

Answer 2

回调解决方案具有很大的可扩展性，而您有时可能希望将行为更改为异步调用。

缺点是您的代码可读性较差，尤其是对于那些初学者程序员。如果这对你来说不是问题，那么确定，继续...

Answer 3

回调参数应包括调用调用的对象。对我来说听起来不错，但使用回调可能会涉及一些同步问题——你不能确定你会在哪个状态下收到回调。并非不可能，但可能需要考虑。

当然，在轮询结果时，您需要在另一端进行同步。但这听起来更容易同步。

Answer 4

我更喜欢回调，因为如果你在多个地方使用它，它会减少代码并提高可读性。通过回调您的 if 语句来确定将发生什么（调用哪个方法）将在执行事务的服务中，并且使用该服务的所有代码看起来都更清晰。