El uso de una devolución de llamada en lugar de devolver objeto de estado

Question

En mi solicitud, estoy ejecutar una transacción que puede estar en tres estados diferentes al final de la ejecución:

• Éxito
• Si no
• Pendiente

Dependiendo del estado, el cliente de aplicación se desea llevar a cabo diferentes acciones. En el caso de éxito, ellos van a querer recuperar el resultado de la transacción (un widget). En el caso de fracaso, ellos van a querer recibir el motivo del error. En el caso de que se encuentre pendiente la transacción, que va a querer programar una hora para volver a intentar. Actualmente puedo devolver un objeto con los métodos siguientes:

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

La idea es que el cliente comprueba el estado del objeto resultado, e invoca el método apropiado en función de su valor, por ejemplo.

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

Estaba pensando que podría ser preferible utilizar una llamada de retorno, por ejemplo.

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

Donde Delay es una clase que representa un TimeUnit y el período, lo que permite la aplicación para reprogramar la ejecución de la transacción. Otra alternativa consiste en lanzar una excepción envolver la causa de fallo (ya que sólo debe fallar en condiciones excepcionales), y mantener los métodos onSuccess y onPending.

Así que mi pregunta SO es la siguiente:? Es el uso de una devolución de llamada un patrón apropiado para este problema particular, o cualquiera puede sugerir algo más apropiado

Answer 1

No creo que este es un buen uso del patrón de devolución de llamada.

Una devolución de llamada es apropiada si el destinatario de la llamada (por ejemplo, la transacción en su caso) tiene que seguir haciendo las cosas según un método de retrollamada devoluciones. Pero si lo próximo que el destinatario de la llamada es siempre lo hace volver a la llamada, a continuación, la devolución de llamada no añade ningún valor. Sólo se hace la estructura del código más complejo y menos legible. OMI, que sería mejor para devolver un objeto de resultado o (en el caso de un fallo excepcional) lanzar una excepción.

Editar -. Re comentario de la OP

Puedo ver el valor de usar un método de devolución de llamada para pedir a la persona que llama si la transacción debe continuar, aunque probablemente habría utilizado un parámetro de tiempo de espera sencilla. Sin embargo, el uso de métodos de devolución de llamada para devolver resultados es (OMI) sigue siendo incorrecto.

Answer 2

Yo prefiero devoluciones de llamada ya que si se utiliza en varios lugares que se traducirá en menos código y sea más fácil de leer. Con llamada de vuelta a su sentencia if para determinar lo que va a ocurrir (el método a llamar) estará en el servicio haciendo la transacción y todo el código que utiliza el servicio sólo se verá más limpio.

Answer 3

Los argumentos de devolución de llamada debe incluir el objeto abastecimiento de la llamada. Suena bien para mí, pero utilizando una devolución de llamada podría implicar algunos problemas de sincronización - no se puede estar seguro de en qué estado recibirá la devolución de llamada. No es imposible, pero puede necesitar consideración.

Por supuesto, con el resultado de votación, lo que se necesita sincronización en el otro lado. Pero eso suena más simple para sincronizar.

Answer 4

solución de devolución de llamada es mucho más extensible, mientras que es posible que en un momento desee cambiar el comportamiento de una llamada asincrónica.

El inconveniente es su código será menos legible, especialmente a aquellos programador principiante. Si eso no es un problema para usted, entonces seguro, seguir ...