Il mittente di un evento dovrebbe sempre essere un oggetto generico?

Question

Il mittente di un evento dovrebbe sempre essere un oggetto generico?

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

8

Quando si programmano eventi in C #, si consiglia di creare un delegato in forma di:

delegate XEventHandler(object sender, XEventArgs e);

La mia domanda è sul primo argomento del delegato, object sender . Dev'essere sempre un generico object ? Avere un mittente di tipo object produce sempre un codice simile a questo.

val = ((ConcreteType)sender).Property;

o, ancora più dettagliato,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

Un argomento contro mittenti strongmente tipizzati è che altri oggetti possono inoltrare l'evento senza preoccuparsi del tipo. Mentre questo potrebbe avere senso negli ambienti GUI, non sono sicuro che potrebbe trarne beneficio al di fuori di una GUI.

Cosa succede se la classe del mittente è sempre nota (almeno come una classe astratta)? Ad esempio, se sto implementando un evento ListChanged in una classe List astratta e se altre classi lo erediteranno (ad esempio LinkedList , ArrayList ), è giusto definire il mio delegato con un mittente di tipo List ?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

Oppure, ci sarebbe uno svantaggio nel cambiare il% convenzionaleobject sender in un tipo più specifico?

c# event

posta Krumia 28.10.2014 - 10:55

fonte

2 risposte

Leggi altre domande sui tag c# event

Cosa dovrei includere nel mio repository dai progetti IDE Quanta logica può essere inserita in un comando? O in modo diverso: che tipo di logica è il modello di comando?

score 9 · Answer 1

A questo punto, è principalmente una (piuttosto strong) convenzione. Cioè, sarà strano se scrivi una libreria che non segue quella convenzione.

Le Linee guida per la progettazione degli eventi dicono:

DO use object as the type of the first parameter of the event handler, and call it sender.

Tuttavia, potresti notare che le linee guida attuali indicano che non devi definire il tuo delegato personalizzato per gli eventi, ma usa EventHandler<T> , se possibile.

Per quanto riguarda il design, suppongo che promuova anche il riutilizzo dei gestori di eventi, anche in contesti non originariamente previsti dal designer originale dell'evento.

score 0 · Answer 2

Il motivo della raccomandazione è che consente modifiche future che non richiedono necessariamente modifiche al codice esistente e, in particolare, all'interfaccia pubblica.

Il meccanismo degli eventi può ancora essere utilizzato per gli eventi in stile "VB6", ma dovrai cambiare tutti i consumatori esistenti se hai bisogno di cambiare la firma (o peggio: creare nuove versioni degli stessi eventi). Con l'approccio consigliato, a condizione che i nuovi articoli ereditino quelli esistenti, puoi aggiornare la firma senza correggere il codice esistente.