Sollte ein Event, das keine Argumente hat, eigene EventArgs definieren oder einfach System.EventArgs verwenden?

Question

Ich habe ein Ereignis, das derzeit ohne Ereignisargumente definiert ist. Das heißt, die EventArgs, die es sendet, ist EventArgs.Empty.

In diesem Fall ist es am einfachsten meine Ereignishandler zu erklären, wie:

EventHandler<System.EventArgs> MyCustomEvent; 

Ich plane nicht auf dieses Ereignis keine Veranstaltung Argumente hinzufügen, sondern es ist möglich, dass jeder Code in ändern müssen könnte die Zukunft.

Daher bin ich darauf ausgerichtet, dass alle meine Ereignisse immer einen leeren Ereignisargumentyp erzeugen, der von System.EventArgs inherher ist, auch wenn momentan keine Ereignisargumente benötigt werden. Etwas wie folgt aus:

public class MyCustomEventArgs : EventArgs 
{ 
} 

Und dann meine Event-Definition wird wie folgt vor:

EventHandler<MyCustomEventArgs> MyCustomEvent; 

Also meine Frage ist: ist es besser, meine eigene MyCustomEventArgs zu definieren, auch wenn er nichts hinzufügen, über Erben von , damit Ereignisargumente in Zukunft leichter hinzugefügt werden können? Oder ist es besser, mein Ereignis explizit als zurückgeben zu definieren, so dass es für den Benutzer klarer ist, dass es keine zusätzlichen Ereignisargumente gibt?

Ich möchte benutzerdefinierte Ereignisargumente für alle meine Ereignisse erstellen, auch wenn die Ereignisargumente leer sind. Aber ich fragte mich, ob andere dachten, dass es besser wäre, dem Benutzer klarzumachen, dass die Ereignisargumente leer sind?

Vielen Dank im Voraus,

Mike

Answer 1

Von Framework Design Guidelines von Brad Abrams und Krzysztof Cwalina:

Betrachten wir eine Unterklasse von EventArgs als das Ereignis Argument, es sei denn, Sie das Ereignis absolut sicher sind, wird nie Event-Handling-Methode dann, alle Daten tragen müssen In diesem Fall können Sie den Typ EventArgs direkt verwenden.

Wenn Sie eine API direkt mit EventArgs versenden, können Sie niemals Daten hinzufügen, die mit dem Ereignis übertragen werden, ohne die Kompatibilität zu beeinträchtigen. Wenn Sie eine Unterklasse verwenden, auch wenn sie anfangs vollständig leer ist, können Sie der Unterklasse bei Bedarf Eigenschaften hinzufügen.

Persönlich denke ich, das kommt auf das Kompatibilitätsproblem. Wenn Sie eine Klassenbibliothek erstellen, die von anderen konsumiert wird, würde ich eine Unterklasse verwenden. Wenn Sie nur die Ereignisse in Ihrem eigenen Code verwenden, dann gilt (wie Alfred gesagt hat) YAGNI. Es wäre eine brechende Änderung, wenn Sie von EventArgs zu Ihrer eigenen abgeleiteten Klasse wechseln, aber da es nur Ihren eigenen Code brechen würde, ist es kein allzu großes Problem.

Answer 2

YAGNI

Ich schlage vor, mit EventArgs zu bleiben und nur noch etwas anderes verwenden, wenn Sie es wirklich brauchen werden.

---

UPDATE:

Wie adrianbanks wies darauf hin, wenn Code von anderen Code verbraucht werden wird, die nicht unter Kontrolle ist (dh Code, den Sie nicht selbst kompilieren können) oder Wenn das erneute Kompilieren von Consumer-Code mühsam ist, sollten Sie EventHandler <YourEventArgs> verwenden.