Bei der Arbeit haben wir ein riesiges Framework und verwenden Ereignisse, um Daten von einem Teil zum anderen zu senden. Ich habe vor kurzem ein persönliches Projekt gestartet und denke oft daran, Ereignisse zu verwenden, um die Interaktionen meiner Objekte zu steuern.
Zum Beispiel habe ich eine Mixer-Klasse, die Klangeffekte spielt, und ich dachte zuerst, dass ich Events bekommen sollte, um einen Sound-Effekt zu spielen. Dann entschied ich mich, meine Klasse nur statisch zu machen und
anzurufen %Vor%in meinen Klassen. Ich habe eine Menge Beispiele wie dieses hier, wo ich zunächst an eine Implementierung mit Ereignissen denke und dann meine Meinung ändere und mir sage, dass es für nichts zu komplex ist.
Wann sollte ich Ereignisse in einem Projekt verwenden? In welchen Fällen haben Ereignisse einen ernsthaften Vorteil gegenüber anderen Techniken?
Im Allgemeinen verwenden Sie Ereignisse, um Abonnenten über Aktionen oder Statusänderungen zu informieren, die für das Objekt aufgetreten sind. Durch die Verwendung eines Ereignisses lassen Sie unterschiedliche Teilnehmer unterschiedlich reagieren, und durch Entkoppeln des Teilnehmers (und seiner Logik) vom Ereignisgenerator wird das Objekt wiederverwendbar.
In Ihrem Mixer-Beispiel würden Ereignisse den Beginn und das Ende der Wiedergabe des Soundeffekts anzeigen. Wenn ich dies in einer Desktop-Anwendung verwenden würde, könnte ich diese Ereignisse verwenden, um Steuerelemente in der Benutzeroberfläche zu aktivieren / deaktivieren.
Der Unterschied zwischen dem Aufruf einer Unterroutine und dem Auslösen von Ereignissen hängt mit folgenden Faktoren zusammen: Spezifikation, Wahl, Kardinalität und letztendlich, welche Seite der Initiator oder der Empfänger Kontrolle hat.
Bei Aufrufen wählt der Initiator , um die empfangende Routine aufzurufen, und der Initiator gibt den Empfänger an. Und dies führt zu einer Viele-zu-eins -Kardinalität , da viele Anrufer wählen können, dieselbe Subroutine aufzurufen.
Bei Ereignissen hingegen löst der Initiator ein Ereignis aus, das von den Routinen empfangen wird, die gewählt haben um dieses Ereignis zu erhalten. Der Empfänger gibt an, welche Ereignisse von welchen Initiatoren empfangen werden. Dies führt dann zu einer Eins-zu-vielen Kardinalität , da eine Ereignisquelle viele Empfänger haben kann.
So hat die Entscheidung über Anrufe oder Ereignisse meistens damit zu tun, ob der Initiator den Empfänger bestimmt oder der Empfänger den Initiator bestimmt.
Es ist ein Kompromiss zwischen Einfachheit und Wiederverwendbarkeit. Lassen Sie uns eine Metapher des Prozesses "Senden der E-Mail" nehmen:
Wenn Sie die Empfänger kennen und diese endlich sind, können Sie sie immer bestimmen, indem Sie sie in die Liste "An" aufnehmen und auf die Schaltfläche "Senden" klicken. Es ist so simpel wie das, was wir die meiste Zeit benutzen. Dies ruft die Funktion direkt auf.
Im Falle einer Mailingliste wissen Sie jedoch nicht im Voraus, wie viele Nutzer Ihre E-Mail abonnieren werden. In diesem Fall erstellen Sie ein Mailing-Listen-Programm, in dem sich die Benutzer anmelden können, und die E-Mail wird automatisch an alle abonnierten Benutzer gesendet. Das ist Ereignismodellierung.
Nun, obwohl in beiden obigen Optionen E-Mails an Benutzer gesendet werden, können Sie besser beurteilen, wann E-Mails direkt gesendet werden und wann das Mailinglistenprogramm verwendet werden soll. Wenden Sie das gleiche Urteil an, hoffen Sie, dass Sie Ihre Antwort bekommen würden:)
Prost,
Ajit.