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

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方法。

所以我的问题是:对于这个特定的问题，使用回调是一种合适的模式，还是有人能提出更合适的建议？

Answer 1

我不认为这是回调模式的一个很好的使用。

如果被调用方(例如，您的情况下的事务)需要在回调方法返回后继续执行任务，则回调是适当的。但是，如果被调用方所做的下一件事总是返回给调用方，那么回调不会增加任何值。它只会使代码结构变得更加复杂和可读性更低。海事组织，最好返回结果对象，或者(在异常失败的情况下)抛出异常。

编辑-是OP的评论。

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

Answer 2

，我更喜欢回调，因为如果您在几个地方使用它，将会减少代码并提高可读性。使用回调if语句来确定将发生什么(要调用的方法)将在服务中执行事务，并且使用该服务的所有代码看起来都会更干净。

Answer 3

回调参数应该包括获取调用的对象。对我来说听起来不错，但使用回调可能会涉及一些同步问题--您无法确定您将以何种状态接收回调。不是不可能，但可能需要考虑。

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