Modi per fare callback, quando e dove

Ecco le mie opinioni sui vari schemi di osservazione. Potrei aggiornare questa lista nel tempo se i commenti sembrano averne bisogno.

1. Richiamata con chiusura : questo è ottimo se hai qualche tipo di cosa one-shot (come una risposta di rete), o più risposte che devono essere gestite tutte allo stesso modo. Non va bene se ti stai aspettando più risposte che devono essere gestite diversamente o tipi diversi di risposte (che richiederebbero una chiusura diversa per ciascun tipo di risposta.) Inoltre non è utile se hai più oggetti interessati nella risposta.
2. Delega con protocollo : ha molto senso se c'è un motivo commerciale perché dovrebbe esserci solo un ascoltatore / osservatore e ha senso che l'osservatore gestisca diversi stati diversi i cambiamenti. In altre parole, se hai più di un oggetto che è interessato all'argomento, quindi la delega non funzionerà. Se finisci con un protocollo che impone solo l'implementazione di un metodo, allora questo modello probabilmente non è una buona idea neanche. Inoltre, se tu avere un osservatore che vuole rintracciare diversi oggetti diversi implementare il protocollo in questione, quindi dovresti probabilmente riconsiderare l'uso di questo modello.
3. Notifica : NSNotificationCenter funziona molto bene per molto messaggi generici o di sistema. Se hai solo un osservatore, o aspettatevi solo che il messaggio venga inviato una volta, allora questa è una scelta sbagliata di modello. Inoltre, questo schema può farti risparmiare molto tempo quando devi inviare un messaggio tra due oggetti disparati in a sistema maturo (cioè, un hack.)
4. Osservazione del valore chiave : funziona bene se l'osservatore lo desidera monitorare lo stato di un singolo campo ma può diventare poco maneggevole se ci provi osservare diversi campi o se vuoi essere informato di alcuni segnale.

Alcuni pattern che non hai menzionato:

1. callback di destinazione / azione : un esempio di questo è UIControl ... Questo ha gli stessi vantaggi e compromessi di un callback con chiusura e I pensare è stato in gran parte sostituito da esso.
2. Metodo astratto / istanza sottoclasse : esiste la modalità classica di implementare un metodo in una sottoclasse per gestire i requisiti di classe base. Il viewDidLoad di UIViewController e simili sono esempi. Un altro modello che è stato ampiamente sostituito da protocolli, ma torna utile se ti capita di avere già il struttura di classe in atto.
3. Futures / Promises : questo pattern presenta gli stessi vantaggi e svantaggi delle chiusure di callback, ma può evitare le chiusure annidate che a volte pop-up.

Infine, c'è programmazione reattiva (ad esempio ReactiveCocoa e RxSwift) che può potenzialmente prendere il posto di tutti i modelli precedenti. Ci vuole un po 'di tempo per imparare, ma una volta capito, puoi gestire tutte le tue esigenze di osservazione con un solo modello.