Utilizzando un callback anziché tornare oggetto di stato

Question

Nella mia domanda, sto eseguendo un'operazione che può essere in tre diversi stati alla fine della esecuzione:

• Successo
• Guasto
• In attesa

A seconda dello stato, l'applicazione client vorrà eseguire diverse azioni. In caso di successo, vorranno recuperare l'esito della transazione (un Widget). In caso di fallimento, vorranno ricevere il motivo dell'errore. Nel caso in cui la transazione è in attesa, vorranno programmare un tempo per riprovare. Attualmente torno un oggetto con i seguenti metodi:

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

L'idea è che il client controlla lo stato dell'oggetto risultato, e invoca il metodo appropriato a seconda del suo valore, per es.

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

Stavo pensando che potrebbe essere preferibile utilizzare un callback, invece, per es.

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

Dove Delay è una classe che rappresenta un TIMEUNIT e il periodo, consentendo l'applicazione di riprogrammare l'esecuzione dell'operazione. Un'altra alternativa è quella di generare un'eccezione avvolgendo alla causa del disturbo (come dovrebbe fallire solo in condizioni eccezionali), e mantenere i metodi onSuccess e onPending.

Quindi la mia domanda a SO è questo: è l'uso di un callback un modello adeguato per questo particolare problema, o qualcuno può suggerire qualcosa di più appropriato

Answer 1

Non credo che questo sia un buon uso del modello di callback.

Una callback è appropriata se il chiamato (ad esempio la transazione nel tuo caso) ha bisogno di continuare a fare le cose secondo un metodo di callback restituisce. Ma se la prossima cosa che il chiamato fa sempre è il ritorno al chiamante, quindi il callback non aggiunge alcun valore. E 'solo rende la struttura del codice più complessa e meno leggibile. IMO, sarebbe meglio per restituire un oggetto risultato o (nel caso di un guasto d'eccezione) un'eccezione.

Modifica -. Re commento del PO

Posso vedere il valore di usare un metodo di callback per chiedere al chiamante se la transazione deve continuare, anche se probabilmente avrei usato un parametro di timeout semplice. Tuttavia, utilizzando i metodi di callback per restituire i risultati è (IMO) ancora sbagliata.

Answer 2

Io preferisco callback in quanto se lo si utilizza in più punti che si tradurrà in meno codice ed essere più leggibile. Con la chiamata indietro il vostro if per determinare che cosa sta per accadere (che metodo da chiamare) sarà al servizio facendo la transazione e tutto il codice che utilizza il servizio sarà solo aspetto più pulito.

Answer 3

Gli argomenti di callback dovrebbero includere l'oggetto di sourcing la chiamata. Suoni bene per me, ma utilizzando un callback potrebbe comportare alcuni problemi di sincronizzazione - non si può essere sicuri in quale stato si riceverà il callback. Non impossibile, ma potrebbe essere necessario considerazione.

Naturalmente con polling il risultato, si avrebbe bisogno di sincronizzazione sul lato opposto. Ma che suona più semplice per sincronizzare.

Answer 4

soluzione Callback è molto estensibile, mentre si può ad un certo punto vuole cambiare il comportamento di una chiamata asincrona.

Lo svantaggio è il vostro codice sarà meno leggibile, soprattutto a coloro programmatore principiante. Se questo non è un problema per voi allora certo, andare avanti ...