Moet ik de parameter “ e ” weglaten bij gebruik van EventHandler < EventArgs >?

Telkens wanneer ik mijn eigen gebeurtenissen definieer, gebruik ik een patroon zoals het volgende (waarvan ik geloof dat is hoe de MSDN aanbeveelt doen):

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

De clientcode hoeft zich dus alleen maar te abonneren op het evenement en het werkt automatisch.

voelt lastig om de parameter EventArgs e door te geven, in het bijzonder met een klasse die EventHandler gebruikt om zijn events te verhogen, aangezien de basis EventArgs geen gegevens bevat, alleen EventArgs.Empty.

Zou het als een faux pas worden beschouwd om het hierin te veranderen?

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

Reacties

• Wat doet het pijn om daar te zijn? Moet u het later opnieuw toevoegen als u gebeurtenisargumenten moet doorgeven? Waarschijnlijk …
• Ik zag het alleen als een gemak om mezelf wat moeite te besparen tijdens het schrijven van de les. Maar u ' heeft volkomen gelijk in de zin dat het kan later veranderen (het heeft waarschijnlijk ' t gewonnen, maar toch …), en het zou een ingrijpende verandering zijn, dus ik kan het net zo goed de eerste keer goed doen. Bedankt!
• In dit specifieke geval is het niet ' Het is normaler om een PropertyChangedEventArgs en -Handler, en geef als argument de eigenschapnaam door? Of is dit slechts een slecht voorbeeld?
• Mijn code is misschien een slecht voorbeeld, maar ik haalde mijn ontwerp- en naamgevingsconventies uit een paar .NET-klassen, die de standaard EventArgs- en -Changed-nomenclatuur gebruiken.