Warum sollten Ereignisse in C # nehmen (sender, EventArgs)?

Question

Es ist bekannt, dass Sie Ereignisse, die nehmen als Parameter (object sender, EventArgs args) zu erklären. Warum?

Answer 1

Dies ermöglicht es den Verbraucher Entwickler die Möglichkeit, einen einzelnen Event-Handler für mehrere Ereignisse, unabhängig von Absender oder Ereignisse zu schreiben.

Edit: Warum würden Sie ein anderes Muster benötigen? Sie können EventArgs erben jede Menge Daten zu liefern, und die Änderung der Muster werden nur jeden Entwickler zu verwirren und frustrieren gehen zu dienen, die dieses neue Muster zu konsumieren gezwungen wird.

Answer 2

Eigentlich ist dies fraglich, ob dies der beste Praxis Weg Ereignisse zu tun ist. Es ist die Schule des Denkens, die als Ereignisse bestimmt sind zwei Codesegmente zu entkoppeln, die Tatsache, dass der Ereignishandler den Absender erhält, und zu wissen, welche Art hat den Sender in, um zu werfen, etwas zu tun mit ihm ein anti- ist Muster.

Answer 3

Weil es ein gutes Muster für jeden Callback-Mechanismus ist, unabhängig von der Sprache. Sie wollen wissen, wer das Ereignis (der Sender) und Daten, die auf das Ereignis relevant ist gesendet (EventArgs).

Answer 4

einen einzigen Parameter verwenden, EventArgs für die von einem Ereignis übergebenen Daten können Sie Daten auf Ihr Event, ohne zu brechen bestehende Verbraucher in zukünftigen Versionen Ihrer Software hinzuzufügen. Sie fügen einfach neue Mitglieder zu einer bestehenden EventArgs abgeleitete Klasse oder eine abgeleitete Klasse mit den neuen Mitgliedern erstellen.

Ansonsten Konsistenz und das Prinzip der geringsten Überraschung rechtfertigen EventArgs für Übergabe von Daten verwendet wird.

Wie für Absender, in einigen (aber nicht allen) Fällen ist es nützlich zu wissen, welche Art der Veranstaltung geschickt. einen anderen Typ als Objekt für den Absender Argument ist zu restriktiv. es, dass andere Absender konnte nicht das gleiche Ereignis Unterschrift Wiederverwendung bedeuten würde

Answer 5

Es ist ein gutes Muster zu verwenden, auf diese Weise, was auch immer das Ereignis implementiert, kann finden, was es sendete.

Auch die EventArgs überschrieben und Weitergabe von Daten über sie ist die beste Methode. Die EventArgs sind eine Basisklasse. Wenn Sie bei verschiedenen Kontrollen aussehen, die Ereignisse nennen, haben sie EventArgs außer Kraft gesetzt, die Sie weitere Informationen über die Veranstaltung gibt.

Auch wenn Sie brauchen nicht die Argumente um das Ereignis zu tun, wenn Sie sie nicht, sie mit dem ersten Lauf des Rahmens umfassen und später hinzufügen möchten, können Sie alle vorherigen Implementierungen brechen, und müssen sie neu schreiben . Plus, wenn Sie ein, einen Rahmen zu schaffen und gehen zu verteilen, dass es noch schlimmer wird, weil jeder, dass Ihr Framework verwendet werden muß Refactoring.

Answer 6

Chris Anderson sagt im Framework Design Guidelines Buch:

  

[T] sein ist nur über ein Muster. Ereignisargumente verpackt in einer Klasse, die Sie besser Versionierung Semantik. Dadurch, dass ein gemeinsames Muster (sender, e) es leicht als Signatur für alle Veranstaltungen gelernt.

Es gibt Situationen, vor allem denen, die Interop-Abweichung von diesem Muster erfordern würde.

Answer 7

Es schien, dass dies Microsoft war Weg, um das Event-Modell im Laufe der Zeit zu entwickeln. Es scheint auch, dass sie auch eine andere Art und Weise erlauben, es zu tun mit den „neuen“ Aktions delegieren und es Variationen.

Answer 8

„Object sender“ ermöglichen ein Verfahren für mehrere Objekte wieder zu verwenden, wenn die Handler-Methode soll etwas mit dem Objekt tun, die das Ereignis ausgelöst hat, für Textbox Beispiel 3 kann einen einzigen Handler hat, die den Text der Brenn Textbox zurückgesetzt .

EventArgs Hauptvorteil ist, dass es Ereignisinformationen, Refactoring, ohne die Notwendigkeit zu ändern Unterschriften aller Handler in allen Projekten, die abonniert werden, um diese Art von Veranstaltung.

erlaubt

Ich kann nicht denken Sie an eine intelligentere Weise mit Ereignissen zu befassen.

Answer 9

Manchmal möchten Sie alle Ihre Veranstaltung Verbraucher zwingen, einen bestimmten Ereignisparameter zu verwenden, beispielsweise ein Sicherheitsereignis, die einen Booleschen Parameter, true für gut geht, falsch für schlecht. In diesem Fall können Sie Ihre Verbraucher sein wollen schmerzlich bewusst den neuen Parameter, das heißt Sie möchten, dass Ihre Verbraucher mit diesem Parameter gekoppelt werden. Beachten Sie, werden Ihre Verbraucher noch entkoppelt von Ihrer Veranstaltung Brennen Klasse, aber nicht von Ihrer Veranstaltung.

Ich vermute, dass dieses Szenario zu einer großen Anzahl von Fällen und in diesen Fällen gilt der Wert von EventArgs stark reduziert wird.

Answer 10

Die EventArgs Klasse allein nutzlos ist, da es mit beliebigem Inhalt instanziiert abgeleitet werden muß. Dies würde bedeuten, eine Unterklasse verwendet werden soll, und viele sind bereits in .NET. Leider kann ich keine gute generische finden.

Angenommen, Sie Protokollierung auf ein generisches Ereignis delegieren mögen ... ohne eigene EventArgs SUBCLASS zu SCHREIBEN. Es kann eine sinnlose Übung scheinen, aber Ich mag vorhandene Funktionen verwenden. Sie können Ihre Schnur durch das Objekt Argument übergeben, aber das geht dagegen Gebrauch bestimmt ist. Versuchen Sie, eine gute Referenz von EventArgs Subklassen auf Google zu finden, und Sie werden trocken kommen. (Zumindest habe ich.)

ReSharper hilft ein wenig, da bei der Eingabe „EventArgs“ eine Liste aller Klassen sehen werden (innerhalb Ihrer Verwendung / Importe scope), die die Zeichenfolge „EventArgs“ ENTHALTEN. Durchsicht der Liste werden Sie viele Klassen ohne String-Mitglieder sehen. Wenn Sie erhalten auf ControlEventArgs , sehen Sie, dass die Eigenschaft Text verwendet werden könnte, aber mit all den Aufwand einer Fenstersteuerung. ConvertEventArgs könnte nützlich sein, da Sie die Art zusammen mit den Daten passieren, aber dies erfordert noch eine enge Kopplung, die weder ist gut dokumentiert noch von Natur aus typsicher. DataReceivedEventArgs hat keine Umsetzung. EntryWrittenEventArgs erfordert eine EventLogEntry mit einem Byte-Array oder Streaming für Daten. ErrorEventArgs ist näher, mit einer Ausnahmemeldung, wenn Sie alle Ihre Log-Ereignisse Ausnahme ErrorEvents Aufruf intern nichts ausmacht. FileSystemEventArgs ist wahrscheinlich der nächste noch mit zwei Saiten und einem erforderlichen WatcherChangeTypes Enum Argument, das auf 0 gesetzt werden kann, wenn Sie wissen, was Sie tun. LabelEditEventArgs verwendet einen int und eine Zeichenfolge, wenn Sie nichts dagegen haben die Windows.Forms Namespace erfordern. RenamedEventArgs ist ähnlich FileSystemEventArgs mit einer zusätzlichen Saite. Schließlich ResolveEventArgs in System.Runtime.InteropServices gibt einen einzelnen String. Es gibt noch andere Bibliotheken, aber ich einige der geläufigsten stecken. Also, abhängig von der Implementierung kann ich ErrorEventArgs , FileSystemEventArgs oder ResolveEventArgs für die Anmeldung.