Czy powinienem pominąć parametr “ e ” podczas korzystania z EventHandler < EventArgs >?

Ilekroć definiuję własne wydarzenia, używam wzorca takiego jak poniższy (który uważam , że jest zalecany przez MSDN robi to):

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

Tak więc kod klienta musi po prostu zasubskrybować zdarzenie i działa automagicznie.

Jednak wydaje się uciążliwe przekazywanie parametru EventArgs e, w szczególności w przypadku klasy, która używa EventHandler do zgłaszania swoich zdarzeń, ponieważ baza EventArgs nie zawiera żadnych danych, a jedynie EventArgs.Empty.

Czy zmiana tego na to nie byłaby uznana za faux pas?

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

Komentarze

• Co boli będąc tam? Czy będziesz musiał dodać go później, gdy okaże się, że musisz przekazać argumenty zdarzenia? Prawdopodobnie …
• Myślałem o tym tylko jako o wygodzie, aby zaoszczędzić sobie trochę wysiłku podczas pisania zajęć. Ale ' masz absolutną rację, ponieważ może zmienić się później (prawdopodobnie wygrał ' t, ale nadal …) i byłaby to przełomowa zmiana, więc równie dobrze mogę zrobić to dobrze za pierwszym razem. Dzięki!
• W tym konkretnym przypadku nie ' t bardziej normalne jest używanie PropertyChangedEventArgs i -Handler i przekazać jako argument nazwę właściwości? A może to tylko zły przykład?
• Mój kod może być złym przykładem, ale wyciągałem mój projekt i konwencje nazewnictwa z kilku klas .NET, które używają domyślnej nomenklatury EventArgs i -Changed.