Puoi esagerare con i delegati e gli eventi

Per me la distinzione tra l'utilizzo di un evento e la chiamata a un metodo è per una corretta separazione delle preoccupazioni.

Quando chiami un metodo, il chiamante sa quale metodo viene chiamato. Quando rilanci un evento, il raiser non sa chi sta ascoltando (se c'è qualcuno).

Un controllo a pulsante è un ottimo esempio di quando un evento è appropriato, perché un controllo a pulsante non deve e non deve essere legato a ciò che fa.

Fondamentalmente con un evento, il metodo effettivo che viene chiamato è una variabile piuttosto che una costante. Ciò lo rende più flessibile, ma allo stesso tempo, se non ha bisogno di cambiare, può rendere il codice più complicato da seguire.

Sì, puoi abusarne.

Alcuni problemi generalmente associati al codice di invio eventi:

• Le seguenti catene di gestori di eventi in modalità di debug sono molto difficili.
• In un ambiente multi-thread, diventa ancora più difficile.
• Spesso si finisce per separare il codice in fasi ("fase di installazione del gestore", "fase di dispacciamento dell'evento")
• Un produttore di lunga data di un evento detiene riferimenti ai suoi consumatori. Ciò impedisce la raccolta di rifiuti di consumatori di breve durata se non viene prestata particolare attenzione.
• Dal momento che il produttore ha riferimenti ai suoi consumatori, è sempre stato. Ci sono scenari in cui lo stato è meglio evitare.

Spesso puoi riscrivere il codice di invio di eventi complicato e ampiamente cablato introducendo una nuova classe la cui unica responsabilità è quella di coordinare un determinato processo.

Direi che la regola più semplice è:

• Se si conosce esattamente quale / i altro / i metodo / i di quale / i altro / i oggetto / i devono / devono essere / i da eseguire, e non è necessario modificarlo in fase di esecuzione, utilizzare una chiamata diretta. Aiuta con la leggibilità.
• Se non puoi sapere in anticipo chi vorrebbe ricevere le informazioni fornite dalla chiamata, quindi utilizzare un evento. Aiuta con flessibilità.

Generalmente gli eventi vengono utilizzati per far scoppiare la reazione del tuo codice all'input dell'utente dai livelli più bassi. Pertanto, le cose come l'aggiornamento di un modulo vengono solitamente eseguite tramite eventi. Ciò consente di scrivere codice MVC corretto, in cui è possibile scrivere facilmente una vista diversa e ricevere le stesse informazioni, ma potrebbe reagire in modo diverso.

Di norma, dovresti usare lo strumento più leggero e più semplice finché svolge il lavoro. Il punto degli eventi è che non conosciamo il gestore eventi in anticipo. Potrebbe essere qualsiasi cosa (qualsiasi metodo, purché le corrispondenze di firma ovviamente). Potremmo aspettarci che ci venga passato da una chiamata da qualche altra biblioteca. Questo è il lusso qui.

Sono sicuro che non è necessario mantenere tutte le opzioni aperte in questo modo. Chiamare manualmente i metodi è molto più semplice, se sai già quali saranno questi metodi. Renderebbe la tua applicazione più facile da capire. Inoltre, può essere un po 'come chiamare gli amici su un telefono cellulare stando di fianco a loro.

Inoltre ci sono alcuni potenziali problemi con gli eventi che potresti incontrare (per esempio durante la serializzazione di oggetti - manterranno il riferimento ai loro listener di eventi di destinazione, quindi tenteranno di serializzarli insieme, il che può dare risultati inattesi e / o eccezioni).