Un evento che non ha argomenti definisce un EventArgs personalizzato o utilizza semplicemente System.EventArgs?

Question

Ho un evento che è attualmente definito senza argomenti evento. Cioè, l'EventArgs che invia è EventArgs.Empty.

In questo caso, è più semplice di dichiarare il mio gestore di eventi come:

EventHandler<System.EventArgs> MyCustomEvent; 

Non ho intenzione di aggiungere argomenti di eventi per questo evento, ma è possibile che qualsiasi codice potrebbe essere necessario modificare in il futuro.

Pertanto, sono propenso a fare in modo che tutti i miei eventi creino sempre un evento vuoto tipo di argomento che eredita da System.EventArgs, anche se non ci sono argomenti di evento attualmente necessari. Qualcosa di simile a questo:

public class MyCustomEventArgs : EventArgs 
{ 
} 

E poi la mia definizione evento diventa il seguente:

EventHandler<MyCustomEventArgs> MyCustomEvent; 

Quindi la mia domanda è questa: è meglio definire il mio MyCustomEventArgs, anche se non aggiunge nulla al di là ereditando da System.EventArgs, in modo che gli argomenti dell'evento possano essere aggiunti in futuro più facilmente? O è meglio definire esplicitamente il mio evento come restituendo System.EventArgs, in modo che sia più chiaro all'utente che non ci sono argomenti di evento aggiuntivi?

Sono propenso a creare argomenti evento personalizzati per tutti i miei eventi, anche se gli argomenti dell'evento sono vuoti. Ma mi chiedevo se gli altri pensassero che rendere più chiaro all'utente che gli argomenti dell'evento sono vuoti sarebbe meglio?

Molto grazie in anticipo,

Mike

Answer 1

Da Framework Design Guidelines da Brad Abrams e Krzysztof Cwalina:

è consigliabile utilizzare una sottoclasse di EventArgs come argomento dell'evento, a meno che non si è assolutamente sicuri l'evento non avrà mai bisogno di portare tutti i dati per il metodo quindi la gestione degli eventi, in tal caso è possibile utilizzare direttamente il tipo EventArgs.

Se si invia un'API utilizzando EventArgs direttamente, non sarà mai possibile aggiungere alcun dato da trasportare con l'evento senza compromettere la compatibilità. Se si utilizza una sottoclasse, anche se inizialmente completamente vuota, sarà possibile aggiungere proprietà alla sottoclasse quando necessario.

Personalmente, penso che questo dipenda dal problema di compatibilità. Se stai facendo una biblioteca di classi per essere consumata da altri, allora userei una sottoclasse. Se stai usando gli eventi solo nel tuo codice, allora (come ha detto Alfred), si applica YAGNI. Sarebbe un cambiamento irrisolto quando si passa da EventArgs alla propria classe derivata, ma dal momento che si romperà solo il proprio codice non è un problema.

Answer 2

YAGNI

mi suggeriscono di attaccare con EventArgs e utilizzare solo un'altra cosa quando si ha realmente diventi bisogno.

---

UPDATE:

Come adrianbanks sottolineato, se il codice sta per essere consumato da altri codici che non è sotto il vostro controllo (cioè il codice che non è possibile compilare da soli) o se ricompilare il codice utente sarà una seccatura, allora dovresti usare EventHandler <YourEventArgs>.