Che cos'è "migliore": un evento che ti dice che è successo qualcosa o che accetta un delegato da chiamare quando l'evento si innesca internamente?

Question

Che cos'è "migliore": un evento che ti dice che è successo qualcosa o che accetta un delegato da chiamare quando l'evento si innesca internamente?

#1 da (3 voti)
#2 da (0 voti)

1

Sto scrivendo una collezione che accetta un parametro time, lo scopo è che dopo che è trascorso il tempo specificato, l'elemento non sarà presente nella collezione.

Voglio che l'utente di questa raccolta sia in grado di agire quando un oggetto viene rimosso dalla raccolta in questa circostanza. Ho due modi diversi per raggiungere questo obiettivo, ma non sono sicuro di doverlo fare. Entrambi gli approcci sembrano diversi, ma il risultato finale è praticamente lo stesso.

Sto facendo questa domanda poiché potrei non notare una piccola (o grande) differenza tra i due e speravo di ottenere una guida.

Approccio A: avere un evento come OnRemovalDueToTimeout che si aspetta qualche funzione che riceve un elemento (ad esempio void foo (T removedElement)). dopo la rimozione vorrei sollevare l'evento

Approccio B: ricevi un delegato con la stessa firma di sopra e chiama quel delegato quando un elemento scade.

design c# delegates event

posta Belgi 19.02.2017 - 16:56

fonte

2 risposte

Leggi altre domande sui tag design c# delegates event

Come condividere nuove funzionalità in un grande progetto multi-modulo [duplicato] aggiornamento degli elementi del database agli utenti "sottoscritti"

score 3 · Answer 1

Fortunatamente per te, tutto il codice che ti serve esiste già in .NET Framework. Si chiama ObservableCollection<T> e consiste in una classe di raccolta che ha l'evento CollectionChanged che viene generato quando un articolo viene aggiunto, rimosso o modificato.

Tutto quello che devi fare è ereditare da questa classe e implementare la logica del timer. Quando il timer scade, rimuove semplicemente un elemento; .NET Framework gestirà la parte eventi.

Se vuoi che l'evento venga generato solo quando il timer è scaduto, e non quando l'elemento qualsiasi viene rimosso dalla raccolta, allora hai bisogno della tua classe. Poiché la maggior parte degli sviluppatori .NET ha già utilizzato ObservableCollection<T> , per semplicità usa la stessa interfaccia. Il nome dell'evento sarebbe diverso, specialmente per indicare che non viene generato quando un elemento viene rimosso, ma l'interfaccia generale dovrebbe avere lo stesso aspetto. Tieni presente che probabilmente il codice sorgente di ObservableCollection<T> ti aiuterà stesura della tua classe.

Per quanto riguarda il caso generale di eventi vs. delegati:

In lingue come JavaScript, i delegati (callback) sono il modo standard per informare il chiamante di qualcosa che accade in futuro.
In lingue come C #, il modo usuale è usare gli eventi. Sebbene tecnicamente, entrambi sono molto simili, .NET Framework e molte applicazioni C # mostrano una preferenza per gli eventi, quindi in base a POLA , gli eventi sarebbero una buona scelta.

score 0 · Answer 2

Generalmente, passare a un delegato è un approccio migliore.

Gli eventi introducono problemi di durata (quando questo oggetto muore, devo annullare la registrazione del gestore di eventi?). Gli eventi richiedono controlli null per ogni chiamata, i delegati possono essere controllati nel costruttore. Gli eventi complicano la gestione degli errori, poiché ogni gestore deve comportarsi in modo tale da non interrompere l'evento per l'altro gestore; poiché i delegati sono passati, ciò diventa responsabilità del chiamante.

In breve, gli eventi introducono un po 'di complessità che non è particolarmente utile al di fuori di uno scenario molto specifico.