Modo preferito per dichiarare eventi

13

Sono abbastanza soddisfatto della mia comprensione del modello di eventi .NET. Penso che potrei fraintendere una piccola sfumatura del sistema.

Quando ho iniziato a inserire eventi nelle mie classi, avrei usato il modo standard in questo modo:

public event EventHandler<MyEventArgs> MyEvent;

Questo significava che qualsiasi cosa iscriversi all'evento avrebbe bisogno di un metodo come:

void HandleThatEvent(object sender, MyEventArgs args){...}

Che è bello, ma ho scoperto che raramente mi interessava il mittente, quindi ha reso gonfie un sacco di firme dei metodi.

Quindi sono passato a dichiarare i miei tipi di delegati

public delegate void MyEventHandler(SomeClass argument);

Che ha ridotto il disordine, ma mi ha lasciato un piccolo problema quando si trattava di scrivere gestori:

eventImplmentor.MyEvent += HandleThatEvent;
.
.
.
void HandleThatEvent(/*oh, um, what arguments does it take? Intellisense isn't telling me*/)

Quindi dovrei tornare alla dichiarazione del delegato e guardare e poi tornare indietro e scriverli, oppure compilarlo e aspettare che venga detto.

Quindi ora, invece, sto usando solo Action , Action<T> o qualsiasi modello adatto.

public event Action<SomeClass> MyEvent;

Così posso passare il mouse sopra l'evento e sapere quali parametri si aspettano.

La mia domanda, dopo tutto questo: esiste una best practice per la dichiarazione di eventi in C #? Dovrei tornare al modo EventHandler<T> o è Action<T> accettabile?

    
posta Matt Ellen 13.04.2011 - 12:16
fonte

1 risposta

7

Per una gestione degli eventi interna semplice, ci sono quelli che usano semplicemente Action o Action<T> , come si propone. Tendo ad usare lo schema standard, incluso il Sender, anche per eventi interni, perché non sai mai quando potresti voler esporre una classe o un evento, e non vorrei la penalità di dover rifattorizzare il metodo dell'evento solo per fare è pubblico.

Sono d'accordo con te sul fatto che la firma della gestione degli eventi sia un po 'più pesante di quanto dovrebbe essere per gli scenari semplici, ma è ben progettata per gestire la migrazione incrementale in quanto potrebbero diventare necessari ulteriori argomenti di evento nel tempo. Nel complesso, vorrei attenermi al modello standard, soprattutto perché, come hai notato, ottieni il supporto IntelliSense solo se lo fai.

Per quello che vale, ci ho messo un po 'di tempo in questo e ho trovato un diverso pattern di gestione degli eventi: Firma evento in .NET - Utilizzo di un" mittente "Strong . L'obiettivo qui non era quello di rimuovere il mittente, ma di renderlo genericamente strong digitato come TSender invece di digitare debolmente come System.Object . Funziona molto bene; tuttavia, uno fa perdere il supporto IntelliSense quando lo fai, quindi c'è uno sfortunato compromesso.

Nel complesso, rimango al modello standard, ma è interessante pensare a modi potenzialmente migliori per farlo.

    
risposta data 13.04.2011 - 12:44
fonte

Leggi altre domande sui tag