Event Design Guidelines

Question

Ich versuche, so viel wie möglich an die Framework Design Guidelines zu halten, selbst wenn ich Klassenbibliotheken entwerfe, die nur für den internen Gebrauch gedacht sind.

Bis zu einem gewissen Grad macht es mir das Leben leichter, da ich mit Code Analysis die Überprüfung von Bereichen automatisiere, in denen ich möglicherweise keine Best Practices verwende.

Aber hier ist ein Fall, wo ich fühle mich sehr gezwungen, nur die Empfehlungen zu ignorieren.

Da die EventArgs-Einschränkung in .NET 4 aus EventHandler entfernt wurde, warum würde heutzutage jemand lieber eine von EventArgs abgeleitete Klasse verwenden (wie unter https://msdn.microsoft.com/en-us/library/ms229011(v=vs.110).aspx vorgeschrieben), anstatt den gewünschten Datentyp direkt zu verwenden und die Kosten für die Zuweisung eines anderen zu vermeiden Objekt und die gewünschten Daten darin einbetten?

Zum Beispiel mit dem folgenden schreiben:

public class ExceptionEventArgs : EventArgs 
{ 
    private readonly Exception _exception; 

    public ExceptionEventArgs(Exception exception) 
    { 
     _exception = exception; 
    } 

    public Exception Exception 
    { 
     get 
     { 
      return _exception; 
     } 
    } 
} 

public event EventHandler<ExceptionEventArgs>; 

ist viel ausführlicher als kostet eine zusätzliche Zuweisung statt:

public event EventHandler<Exception>; 

Ich habe sogar ein generisches EventArgs für auf einem anderen Klasse mit vor ein paar Wochen, aber ich fühle mich dumm, nur um der Richtlinien zu folgen.

public class EventArgs<T> : EventArgs 
{ 
    private readonly T _data; 

    public EventArgs(T data) 
    { 
     _data = data; 
    } 

    public T Data 
    { 
     get 
     { 
      return _data; 
     } 
    } 
} 

So gibt es irgendwelche Nachteile für die Verwendung von

EventHandler<NotAnEventArgsDerivedClass> 

für die Klassen für die internen * Gebrauch bestimmt?

* Damit meine ich wirklich, für den Einsatz auf einem Produkt bestehend aus mehreren Baugruppen - die alle für die ausschließliche Verwendung durch das Produkt bestimmt sind.

Answer 1

Es ist vorzuziehen nicht von EventArgs erben. Es gibt keine Nachteile mit

EventHandler<NotAnEventArgsDerivedClass> 

aber es macht immer noch die Annahme, dass Sie wollen sender als object passieren, wenn kann es oder auch nicht Sinn sender überhaupt Pass.

Die Verwendung von EventArgs ist der einzige Fall, an den ich denken kann, wo es üblich ist, von einer Klasse aufgrund von Konventionen zu erben, wenn wir nicht wirklich die Klasse benötigen, von der wir erben. Ebenso ist der Standardbeauftragte Handler(object sender, EventArgs e) der einzige Fall, den ich kenne, wo es üblich ist, eine Methodensignatur basierend auf Konvention und nicht auf den Anforderungen für diese spezifische Methode zu entwerfen. Es ermutigt uns, einen untypisierten Parameter zu übergeben, wenn es für uns überhaupt Sinn macht, den Sender überhaupt zu passieren. Es führt zu Methoden, bei denen wir Argumente ignorieren, den Werten von Argumenten nicht vertrauen und Objekte auf spezifischere Typen anwenden, weil wir "nur" wissen, was sie wirklich sind.

Wie in jedem anderen Design sollten wir die Methoden erstellen, die wir brauchen, und die Parameter übergeben, die wir brauchen. Es mag Fälle geben, in denen Konventionen nützlich sind, aber das gehört nicht dazu.