¿Debo omitir el parámetro “ e ” cuando utilizo EventHandler < EventArgs >?

Siempre que estoy definiendo mis propios eventos, uso un patrón como el siguiente (que creo es como recomienda MSDN haciéndolo):

public class MyEventClass { private bool _value; // Backing variable public bool Value { get { return _value; } set { if (value != _value) // Only raise event if value is changed/different { _value = value; OnValueChanged(EventArgs.Empty); } } } public event EventHandler ValueChanged; // Anything can subscribe to the event protected void OnValueChanged(EventArgs e) // Only this and children can invoke event { if (ValueChanged != null) ValueChanged(this, e); } } 

Por lo tanto, el código del cliente solo necesita suscribirse al evento y funciona automáticamente.

Sin embargo, Se siente incómodo pasar el parámetro EventArgs e, en particular con una clase que usa EventHandler para generar sus eventos, ya que el EventArgs base no tiene datos, solo EventArgs.Empty.

¿Se consideraría un paso en falso cambiarlo a esto?

protected void OnValueChanged() { if (ValueChanged != null) ValueChanged(this, EventArgs.Empty); } 

Comentarios

• ¿Qué le duele estar allí? ¿Tendrá que volver a agregarlo más tarde cuando encuentre la necesidad de pasar argumentos de evento? Probablemente …
• Solo lo pensé como una conveniencia para ahorrarme un poco de esfuerzo mientras escribía la clase. Pero usted ' tiene toda la razón en que podría cambiar más tarde (probablemente ganó ' t, pero aún así …), y sería un cambio radical, por lo que también puedo hacerlo bien la primera vez. ¡Gracias!
• En este caso particular, ¿no es ' más normal usar un PropertyChangedEventArgs y un -Handler y pasar como argumento el nombre de la propiedad? ¿O es solo un mal ejemplo?
• Mi código podría ser un mal ejemplo, pero estaba sacando mi diseño y convenciones de nomenclatura de algunas clases .NET, que usan la nomenclatura predeterminada EventArgs y -Changed.