Ska jag utelämna parametern “ e ” när jag använder EventHandler < EventArgs >?

När jag definierar mina egna händelser använder jag ett mönster som följande (som jag tror är hur MSDN rekommenderar gör det):

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); } } 

Klientkoden behöver alltså bara prenumerera på händelsen och den fungerar automatiskt.

Men den känns besvärlig att skicka EventArgs e -parametern, särskilt med en klass som använder EventHandler för att höja sina händelser, eftersom basen EventArgs inte har några data till sig, bara EventArgs.Empty.

Skulle det betraktas som en faux pas att ändra det till detta?

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

Kommentarer

• Vad skadar det att vara där? Måste du lägga till det senare när du hittar ett behov av att skicka händelseargument? Förmodligen …
• Jag tänkte bara på det som en bekvämlighet att spara lite ansträngning när jag skrev lektionen. Men du ' har helt rätt i att det kunde ändras senare (det vann förmodligen ' t, men ändå …), och det skulle vara en brytande förändring, så jag kan lika gärna göra det rätt första gången. Tack!
• I det här fallet är det inte ' t är det mer normalt att använda PropertyChangedEventArgs och -Handler och skicka egenskapens namn som argument? Eller är detta bara ett dåligt exempel?
• Min kod kan vara ett dåligt exempel, men jag tog min design och namngivningskonventioner från några .NET-klasser, som använder standard EventArgs och -Changed nomenklatur.