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

我更喜欢回调，因为如果你在几个地方使用它，它将导致更少的代码并且更具可读性。回调你的if语句以确定将要发生的事情（要调用的方法）将在执行事务的服务中，并且使用该服务的所有代码看起来都会更清晰。

Answer 2

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

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

编辑 - 重申OP的评论。

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

Answer 3

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

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

Answer 4

回调解决方案是可扩展的，而您可能曾经想要将行为更改为异步调用。

缺点是你的代码可读性会降低，特别是那些初学程序员。如果这不是你的问题，那么请继续......

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

4 个答案: