Quando utilizzare (o non utilizzare) un delegato

Question

Questa è una domanda piuttosto generica, ma oggi mi chiedevo dei delegati. A questo punto non ho un tempo specifico in cui li uso o non li uso - a parte casi ovvi, come il passare le selezioni da un raccoglitore o da una tabella. Ad esempio, se c'è una situazione in cui posso passare un riferimento a un oggetto e usarlo per chiamare metodi, c'è un motivo per implementare un delegato? In sintesi, qual è il pattern delegato da usare e quando è meglio NON usarlo?

Grazie per le risposte rapide e complete! Erano tutti estremamente utili.

Answer 1

Il vantaggio di il modello delegato è un accoppiamento lento tra l'oggetto delegante e il suo delegato. L'accoppiamento lento migliora la riusabilità di una classe in altri contesti.

L'oggetto delegante non deve sapere nulla sull'oggetto con cui comunica (a parte il requisito che implementa il protocollo delegato) - soprattutto non la sua classe o i metodi che ha. Se in seguito si desidera riutilizzare il componente in un contesto diverso o farlo comunicare con un altro oggetto di una classe diversa, tutto ciò che questo oggetto deve fare è implementare il protocollo delegato. L'oggetto delegante non deve essere affatto cambiato.

C'è anche uno svantaggio di questo, ovviamente, e cioè che è richiesto un po 'più di codice e il codice che scrivi non è così esplicito e quindi potrebbe essere un po' più difficile da capire. Se questo (generalmente piccolo) compromesso vale la pena dipende dal tuo caso d'uso. Se i due oggetti sono strettamente accoppiati e la probabilità di riutilizzo in futuro è bassa, l'uso del modello delegato potrebbe essere eccessivo.

Answer 2

Vedi this discussione

Un delegato permette un oggetto di inviare messaggi a un altro oggetto quando un evento si verifica.

Pro

• sintassi molto severa. Tutti gli eventi da ascoltare sono chiaramente definiti in il protocollo delegato.

• Tempo di compilazione Avvisi/Errori se un metodo non è implementato come dovrebbe essere un delegato.

• Protocollo definito solo nell'ambito del controller.

• Molto facilmente rintracciabile e facile da identificare il flusso di controllo all'interno di un'applicazione.

• Possibilità di disporre di più protocolli definiti un controller, ciascuno con delegati diversi.

• Nessun oggetto di terze parti richiesto per mantenere/monitorare il processo di comunicazione.

• Possibilità di ricevere un valore restituito da un metodo di protocollo chiamato. Ciò significa che un delegato può aiutare a fornire informazioni indietro a un controller.

Contro

• Molte linee di codice richiesti per definire: 1. la definizione protocollo, 2. la struttura sono delegato nel controllore, e 3. l'attuazione delle definizioni metodo delegato all'interno del delegato stesso.

• È necessario fare attenzione a impostare correttamente i delegati su nil nella deallocazione di oggetti, in caso contrario si possono causare blocchi di memoria chiamando metodi su oggetti deallocati.

• Anche se possibile, può essere difficile e il modello in realtà non si presta ad avere più delegati lo stesso protocollo in un controllore (risposta più oggetti nello stesso evento)

Answer 3

Il "caso d'uso" per la delega è praticamente lo stesso dell'ereditarietà, ovvero l'estensione di un comportamento di classe in modo polimorfico.

Questo è come il wikipedia definisce delegazione:

in ingegneria del software, il modello di delega è un design pattern nella programmazione orientata agli oggetti cui un oggetto, invece di eseguire uno dei suoi compiti prefissati, delegati che compito a un oggetto helper associato. Esiste un'inversione della responsabilità in cui a un oggetto helper, noto come delegato, viene assegnata la responsabilità di eseguire un'attività per il delegante. Il modello di delega è uno dei modelli di astrazione fondamentali alla base di altri modelli software come la composizione (detta anche aggregazione), i mix e gli aspetti.

ci sono, ovviamente, molte differenze tra delega e l'eredità, ma il più grande è, IMO, che l'eredità è un (aka, in fase di compilazione) rapporto fisso tra due classi, mentre la delega può essere definito in fase di esecuzione -time (in lingue che supportano questo). D'altra parte, l'ereditarietà offre un migliore supporto per il polimorfismo.

La delega è un argomento enorme (come l'ereditarietà), e si può leggere molto a riguardo. Alla fine, decidere se utilizzare la delega o l'ereditarietà si riduce a decidere se si desidera una relazione "è-a" o "ha-a", quindi non è così facile elencare le linee guida per la scelta.

Per me, in fondo, la decisione di creare un delegato viene dalla constatazione che:

1. mio codice presenta una serie di comportamenti omogenei (omogenei qui significa che può essere riconosciuto come avendo una natura comune" ");

2. tali comportamenti possono essere "personalizzati" per casi particolari (come in, sostituiti da comportamenti alternativi).

Questa è la mia opinione personale e una descrizione del modo in cui riesco a identificare gli schemi di "delega". Probabilmente ha molto a che fare con il fatto che la mia disciplina di programmazione è fortemente influenzata dal principio del refactoring.

In realtà, IMO, la delega è un modo per definire i punti di "personalizzazione" per la classe. Ad esempio, se si dispone di una sorta di flusso di lavoro astratto, in cui ad ogni passaggio si agisce in base a determinate condizioni; e inoltre quelle azioni concrete potrebbero essere sostituite da altre di un altro tipo, quindi vedo la possibilità di riutilizzarle attraverso la delega.

Spero che questo aiuti.