Zum Beispiel habe ich eine Basis-Ereignisveröffentlichungsmethode:
%Vor% Für eine abgeleitete Klasse, die OnSomeEvent überschreibt und beim Zünden ein zusätzliches Ereignis auslöst:
Und wenn die Ableitung so weitergeht, wird es für jede Generation abgeleiteter Klassen, die dies erfordern, ein neues abgeleitetes EventArgs erzeugen. Es scheint jedoch, dass verschiedene Ableitungen von EventArgs auf dem .NET-Framework nicht veränderbar sind (keine Setter), dies hält ein Objekt davon ab, eine einzige Instanz von EventArgs zu behalten und es so zu modifizieren, wie es geht.
Jedes Mal, wenn ein Ereignis wie dieses ausgelöst wird, wird der Speicher für alle beteiligten EventArgs -Objekte neu zugewiesen. In einer grafikintensiven Anwendung, bei der ein Ereignis dutzende Male pro Sekunde ausgelöst werden kann (z. B. OnPaint event auf einem Steuerelement), ist das wirklich eine gute Übung?
Soll ich Änderungen an OnExtendedEvent() vornehmen und ExtendedEventArgs mutable so ändern, dass Folgendes möglich ist?
BEARBEITEN: Der Beispielcode wurde korrigiert, sollte jetzt klarer sein.
Ich würde jedes Mal, wenn es ausgelöst wird, ein neues unveränderliches Objekt erstellen, da in den Ereignisargumenten Werte vorhanden sind.
Der Hauptgrund ist, was passieren würde, wenn ein neues Ereignis erneut ausgelöst wird, während ein bestehendes Ereignis behandelt wird?
Dies wird möglicherweise in Multithread-Anwendungen passieren, kann aber auch in einem einzelnen Thread auftreten, wie das folgende Beispiel zeigt:
Das erste Ereignis wird mit den folgenden Werten ausgelöst:
%Vor%Dann bewirkt der erste Event-Handler, dass das Event mit den folgenden Argumenten erneut ausgelöst wird:
%Vor%Alle Ereignisbehandlungsroutinen für das zweite Ereignis werden verarbeitet, und jetzt sind wir wieder bei der Verarbeitung der restlichen Ereignisbehandlungsroutinen für das erste Ereignis.
Jetzt, da das gleiche Objekt verwendet wird, haben alle Event-Handler für das erste Event jetzt "Fire 2" als someProperty1, da das zweite Event die Werte überschrieben hat.
Als @nobugz erwähnt haben Sie keine Angst, kurzlebigen Müll zu erstellen.
Zunächst einmal, warum sollten Sie Ihrer Auslösemethode ein EventArgs-Argument übergeben, wenn Sie es ohnehin ignorieren? Das ist die wirkliche Verschwendung, aber der Ressourcenverbrauch ist weniger problematisch als die Lüge, die Ihre Methode ihren Anrufern mitteilt. Übergeben Sie das Argument einfach durch, Ihre Brennmethode wird wahrscheinlich keine relevanten Informationen verfügbar haben, um das EventArgs-Objekt trotzdem zu erstellen:
%Vor%Nun, da wir das gerade haben, wenn Ihr EventArgs-Objekt keine aussagekräftigen Informationen für Ihre Abonnenten hat, verwenden Sie einfach EventArgs.Empty, wofür es da ist. Sie könnten dasselbe Muster für Ihre benutzerdefinierten EventArgs-Klassen verwenden, aber ehrlich gesagt, Sie sorgen sich um nichts. Das Erstellen von EventArgs-Objekten wird in Ihrer Anwendung niemals zu einem Engpass führen. Ist dies der Fall, haben Sie Probleme mit dem Entwurf.
Ich bin ein wenig verwirrt durch Ihren OnExtendedEvent -Code - wollen Sie das Ereignis als SomeEvent ? weiterleiten?
Wenn ein Client einen Ereignishandler hinzufügt, erwartet er, dass er den Ereignishandler entfernen kann, während er das Ereignis behandelt:
%Vor%Wenn Sie die Standard-Dispatching-Praxis nicht befolgen, wird dieser Code eine Exception sehr zur Überraschung der Person, die Ihren Code verwendet, auslösen.
Tags und Links c# events event-handling eventargs