¿Debería un evento que no tiene argumentos definir sus propios EventArgs personalizados o simplemente usar System.EventArgs en su lugar?

Question

Tengo un evento que actualmente está definido sin argumentos de evento. Es decir, los EventArgs que envía son EventArgs.Empty.

En este caso, es más simple para declarar mi manejador de eventos como:

EventHandler<System.EventArgs> MyCustomEvent; 

No pienso en la adición de los argumentos de eventos para este evento, pero es posible que cualquier código podría necesitar cambiar de el futuro.

Por lo tanto, me inclino a que todos mis eventos siempre creen un tipo de argumentos de evento vacío que inheretis desde System.EventArgs, incluso si no hay argumentos de eventos actualmente necesarios. Algo como esto:

public class MyCustomEventArgs : EventArgs 
{ 
} 

Y entonces mi definición de evento se convierte en la siguiente:

EventHandler<MyCustomEventArgs> MyCustomEvent; 

Así que mi pregunta es la siguiente: ¿es mejor para definir mi propia MyCustomEventArgs, incluso si no se le añade nada más allá heredando de System.EventArgs, para que los argumentos del evento puedan agregarse en el futuro más fácilmente? ¿O es mejor definir explícitamente mi evento como return System.EventArgs, para que quede más claro para el usuario que no hay eventos adicionales?

Me inclino por crear argumentos de eventos personalizados para todos mis eventos, incluso si los argumentos del evento están vacíos. Pero me preguntaba si otros pensaban que aclarar al usuario que los argumentos del evento están vacíos sería mejor.

Muchas gracias por adelantado,

Mike

Answer 1

De Framework Design Guidelines por Brad Abrams y Krzysztof Cwalina:

considerar el uso de una subclase de EventArgs como el argumento de evento, a menos que esté absolutamente seguro de que el evento nunca tendrá que realizar ningún dato a método a continuación, manejo de eventos, en ese caso puede usar el tipo EventArgs directamente.

Si envía una API usando EventArgs directamente, nunca podrá agregar ningún dato para incluir en el evento sin romper la compatibilidad. Si usa una subclase, incluso si inicialmente está completamente vacía, podrá agregar propiedades a la subclase cuando sea necesario.

Personalmente, creo que esto se debe al problema de compatibilidad. Si está creando una biblioteca de clases para ser consumida por otros, entonces usaría una subclase. Si solo está utilizando los eventos en su propio código, entonces (como ha dicho Alfred), se aplica YAGNI. Sería un cambio radical cuando cambie de EventArgs a su propia clase derivada, pero como solo rompería su propio código, no es demasiado problema.

Answer 2

YAGNI

que sugieren que pegarse con EventArgs y sólo utilizar otra cosa cuando realmente se convierte a necesitarlo.

---

ACTUALIZACIÓN:

Como adrianbanks señalaron, si su código va a ser consumida por cualquier otro código que no está bajo su control (es decir código que no se puede compilar tu mismo) o si recompilando el código del consumidor será una molestia, entonces debe usar EventHandler <YourEventArgs>.