it-swarm.com.de

Wie funktioniert ein Event Listener?

Während eines meiner heutigen Vorträge über Unity haben wir die Aktualisierung unserer Spielerposition besprochen, indem wir jedes Bild überprüft haben, ob der Benutzer eine Taste gedrückt hat. Jemand sagte, dies sei ineffizient und wir sollten stattdessen einen Ereignis-Listener verwenden.

Meine Frage ist, unabhängig von der Programmiersprache oder der Situation, in der sie angewendet wird, wie ein Ereignis-Listener funktioniert.

Meine Intuition würde davon ausgehen, dass der Ereignis-Listener ständig überprüft, ob das Ereignis ausgelöst wurde, was bedeutet, dass es in meinem Szenario nicht anders ist, als jeden Frame zu überprüfen, ob das Ereignis ausgelöst wurde.

Basierend auf der Diskussion im Unterricht scheint es, dass der Ereignis-Listener anders funktioniert.

Wie funktioniert ein Event Listener?

128
Gary Holiday

Im Gegensatz zu dem von Ihnen bereitgestellten Abfragebeispiel (bei dem die Schaltfläche in jedem Frame überprüft wird) überprüft ein Ereignis-Listener nicht, ob die Schaltfläche überhaupt gedrückt wird. Stattdessen wird es aufgerufen, wenn die Taste gedrückt wird.

Vielleicht wirft dich der Begriff "Event Listener" um. Dieser Begriff deutet darauf hin, dass der "Zuhörer" aktiv etwas tut, um zuzuhören, obwohl er überhaupt nichts tut. Der "Listener" ist lediglich eine Funktion oder Methode, die das Ereignis abonniert hat. Wenn das Ereignis ausgelöst wird, wird die Listener-Methode ("Ereignishandler") aufgerufen.

Der Vorteil des Ereignismusters besteht darin, dass keine Kosten anfallen, bis der Knopf tatsächlich gedrückt wird. Das Ereignis kann auf diese Weise behandelt werden, ohne überwacht zu werden, da es von einem sogenannten "Hardware-Interrupt" stammt, der den laufenden Code kurzzeitig vor dem Auslösen des Ereignisses schützt.

Einige UI- und Game-Frameworks verwenden eine sogenannte "Nachrichtenschleife", die Ereignisse für die Ausführung in einem späteren (normalerweise kurzen) Zeitraum in die Warteschlange stellt. Sie benötigen jedoch noch einen Hardware-Interrupt, um dieses Ereignis überhaupt in die Nachrichtenschleife zu bringen.

143
Robert Harvey

Ein Ereignis-Listener, der einem E-Mail-Newsletter-Abonnement ähnelt (Sie registrieren sich, um Updates zu erhalten, deren Übertragung später vom Absender initiiert wird), anstatt eine Webseite (bei der Sie die Übertragung von Informationen initiieren) endlos zu aktualisieren.

Ein Ereignissystem wird mithilfe von Ereignisobjekten implementiert, die eine Liste von Abonnenten verwalten. Interessierte Objekte (genannt Abonnenten, Listener, Delegierte usw.) können sich abonnieren, um über ein Ereignis informiert zu werden, indem sie eine Methode aufrufen, die sich selbst abonniert zum Ereignis, wodurch das Ereignis sie zu seiner Liste hinzufügt. Immer wenn das Ereignis ausgelöst ist (Terminologie kann auch Folgendes umfassen: aufgerufen, ausgelöst, aufgerufen, ausführen) usw.) ruft jeder Teilnehmer die entsprechende Methode auf, um ihn über das Ereignis zu informieren und alle Kontextinformationen weiterzugeben, die er benötigt, um zu verstehen, was passiert ist.

Die kurze, unbefriedigende Antwort lautet, dass die Anwendung ein Signal (das Ereignis) empfängt und dass die Routine nur an diesem Punkt aufgerufen wird.

Die längere Erklärung ist etwas komplizierter.

Woher kommen Kundenveranstaltungen?

Jede moderne Anwendung hat eine innere, normalerweise halb versteckte "Ereignisschleife", die Ereignisse an die richtigen Komponenten sendet, die sie empfangen sollen. Beispielsweise wird ein "Klick" -Ereignis an die Schaltfläche gesendet, deren Oberfläche an den aktuellen Mauskoordinaten sichtbar ist. Dies ist auf der einfachsten Ebene. In der Realität führt das Betriebssystem einen Großteil dieses Versands durch, da einige Ereignisse und einige Komponenten Nachrichten direkt empfangen.

Woher kommen Bewerbungsereignisse?

Betriebssysteme senden Ereignisse aus, sobald sie eintreten. Sie tun dies reaktiv, indem sie von ihren eigenen Fahrern benachrichtigt werden.

Wie generieren Fahrer Ereignisse?

Ich bin kein Experte, aber einige verwenden mit Sicherheit CPU-Interrupts: Die von ihnen gesteuerte Hardware löst einen Pin in der CPU aus, wenn neue Daten verfügbar sind. Die CPU löst den Treiber aus, der die eingehenden Daten verarbeitet, die schließlich eine (Warteschlange von) zu versendenden Ereignissen erzeugen, und gibt dann die Steuerung an das Betriebssystem zurück.

Wie Sie sehen, wird Ihre Anwendung nicht immer ausgeführt. Es ist eine Reihe von Prozeduren, die vom Betriebssystem (sorta) ausgelöst werden, wenn Ereignisse eintreten, aber den Rest der Zeit nichts tun.


 Es gibt bemerkenswerte Ausnahmen, z. Spiele für einmal, die Dinge anders machen könnten

38
Sklivvz

Terminologie

  • Ereignis: Eine Art von Dingen, die passieren können.

  • Ereignisauslösung: Ein bestimmtes Auftreten eines Ereignisses; ein Ereignis passiert.

  • Ereignis-Listener: Etwas, das nach Ereignisauslösungen Ausschau hält.

  • Ereignishandler: Dies tritt auf, wenn ein Ereignis-Listener einen Ereignisauslöser erkennt.

  • Ereignisabonnent: Eine Antwort, die der Ereignishandler aufrufen soll.

Diese Definitionen hängen nicht von der Implementierung ab, sodass sie auf unterschiedliche Weise implementiert werden können.

Einige dieser Begriffe werden häufig mit Synonymen verwechselt, da Benutzer häufig nicht zwischen ihnen unterscheiden müssen.

Häufige Szenarien

  1. Programmierlogische Ereignisse.

    • Das Ereignis ist, wenn eine Methode aufgerufen wird.

    • Ein Ereignis wird ausgelöst ist ein bestimmter Aufruf dieser Methode.

    • Der Ereignis-Listener ist ein Hook in der Ereignismethode, die bei jedem Ereignis ausgelöst wird, das den Ereignishandler aufruft.

    • Der Ereignishandler Ruft eine Sammlung von Ereignisabonnenten auf.

    • Die Ereignisabonnenten führen alle Aktionen aus, die das System als Reaktion auf das Auftreten des Ereignisses ausführen soll.

  2. Externe Ereignisse.

    • Das Ereignis ist ein externes Ereignis, das aus Observablen abgeleitet werden kann.

    • Ein Ereignis wird ausgelöst ist, wenn dieses externe Ereignis als aufgetreten erkannt werden kann.

    • Der Ereignis-Listener erkennt irgendwie Ereignisauslöser, häufig durch Abfragen der beobachtbaren Daten, und ruft dann den Ereignishandler auf, wenn ein Ereignis ausgelöst wird.

    • Der Ereignishandler Ruft eine Sammlung von Ereignisabonnenten auf.

    • Die Ereignisabonnenten führen alle Aktionen aus, die das System als Reaktion auf das Auftreten des Ereignisses ausführen soll.

Polling vs. Einfügen von Haken in den Auslösemechanismus des Ereignisses

Der Punkt, den andere gemacht haben, ist, dass Abstimmungen oft nicht notwendig sind. Dies liegt daran, dass Ereignis-Listener implementiert werden können, indem Ereignisauslöser automatisch den Ereignishandler aufrufen. Dies ist häufig die effizienteste Methode, um Dinge zu implementieren, wenn die Ereignisse auf Systemebene auftreten.

Analog dazu müssen Sie nicht jeden Tag in Ihrem Postfach nach der Post suchen, wenn der Postangestellte an Ihre Tür klopft und die Post direkt an Sie weitergibt.

Ereignis-Listener können jedoch auch durch Abfragen arbeiten. Bei der Abfrage muss nicht unbedingt ein bestimmter Wert oder ein anderes beobachtbares Element überprüft werden. es kann komplexer sein. Insgesamt besteht der Punkt der Abfrage jedoch darin, zu schließen, wann ein Ereignis aufgetreten ist, auf das reagiert werden kann.

Analog dazu müssen Sie Ihr Postfach jeden Tag überprüfen, wenn der Postangestellte nur Post hineinschickt. Sie müssten diese Wahlarbeit nicht durchführen, wenn Sie den Postangestellten anweisen könnten, an Ihre Tür zu klopfen, aber das ist oft nicht möglich.

Verkettung der Ereignislogik

In vielen Programmiersprachen können Sie ein Ereignis schreiben, das nur aufgerufen wird, wenn eine Taste auf der Tastatur gedrückt wird oder zu einem bestimmten Zeitpunkt. Obwohl dies externe Ereignisse sind, müssen Sie nicht nach ihnen abfragen. Warum?

Dies liegt daran, dass das Betriebssystem für Sie abfragt. Beispielsweise sucht Windows nach Änderungen des Tastaturstatus. Wenn eine solche erkannt wird, werden Ereignisabonnenten angerufen. Wenn Sie also ein Tastendruckereignis abonnieren, abonnieren Sie tatsächlich ein Ereignis, das selbst Abonnent eines abrufenden Ereignisses ist.

Nehmen Sie analog an, Sie wohnen in einem Apartmentkomplex und ein Postangestellter gibt die Post in einem gemeinschaftlichen Posteingangsbereich ab. Dann kann ein betriebssystemähnlicher Mitarbeiter für alle nach dieser E-Mail suchen und die E-Mails an die Wohnungen derjenigen senden, die etwas erhalten haben. Dies erspart allen anderen die Mühe, den Posteingangsbereich abfragen zu müssen.


Meine Intuition würde davon ausgehen, dass der Ereignis-Listener ständig überprüft, ob das Ereignis ausgelöst wurde, was bedeutet, dass es in meinem Szenario nicht anders ist, als jeden Frame zu überprüfen, ob das Ereignis ausgelöst wurde.

Basierend auf der Diskussion im Unterricht scheint es, dass der Ereignis-Listener anders funktioniert.

Wie funktioniert ein Event Listener?

Wie Sie vermutet haben, funktioniert ein Ereignis kann durch Abfragen. Und wenn ein Ereignis irgendwie mit externen Ereignissen zusammenhängt, z. Wenn eine Tastaturtaste gedrückt wird, muss irgendwann eine Abfrage erfolgen.

Es ist nur auch wahr, dass Ereignisse nicht unbedingt Abfragen beinhalten müssen. Wenn das Ereignis beispielsweise beim Drücken einer Schaltfläche auftritt, ist der Ereignis-Listener dieser Schaltfläche eine Methode, die das GUI-Framework möglicherweise aufruft, wenn es feststellt, dass ein Mausklick auf die Schaltfläche trifft. In diesem Fall musste noch eine Abfrage stattfinden, damit der Mausklick erkannt wurde, aber der Maus-Listener ist ein passiveres Element, das durch Ereignisverkettung mit dem primitiven Abrufmechanismus verbunden ist.

Update: Bei Hardware-Abfragen auf niedriger Ebene

Es stellt sich heraus, dass USB-Geräte und andere moderne Kommunikationsprotokolle über faszinierende netzwerkähnliche Protokolle für Interaktionen verfügen, die es E/A-Geräten einschließlich Tastaturen und Mäusen ermöglichen, sich mit ad hoc Topologien zu befassen.

Interessanterweise sind " Interrupts" ziemlich zwingende, synchrone Dinge, daher behandeln sie keine ad hoc Netzwerktopologien. Um dies zu beheben, wurden " Interrupts" in asynchrone Pakete mit hoher Priorität verallgemeinert, die " Interrupt-Transaktionen" (im Kontext von USB) oder " Interrupts mit Nachrichtensignal" (im Kontext von PCI). Dieses Protokoll wird in einer USB-Spezifikation beschrieben:

(enter image description here

- " Abbildung 8-31. Host-Statusmaschine für Massen-/Steuerungs-/Interrupt-OUT-Transaktionen" in "Universal Serial Bus Specification, Revision 2.0" , gedruckte Seite-222 ;; PDF-Seite-250 (2000-04-27)

Das Wesentliche scheint zu sein, dass E/A-Geräte und Kommunikationskomponenten (wie USB-Hubs) im Grunde genommen wie Netzwerkgeräte funktionieren. Sie senden also Nachrichten, für die ihre Ports und dergleichen abgefragt werden müssen. Dies verringert den Bedarf an dedizierten Hardwareleitungen.

Betriebssysteme wie Windows scheinen den Abfrageprozess selbst zu handhaben, z. wie in der MSDN-Dokumentation für das USB_ENDPOINT_DESCRIPTOR 's Hier wird beschrieben, wie gesteuert wird, wie oft Windows einen USB-Host-Controller nach Interrupt-/isochronen Nachrichten abfragt:

Der Wert bInterval enthält das Abfrageintervall für Interrupt- und isochrone Endpunkte. Bei anderen Endpunkttypen sollte dieser Wert ignoriert werden. Dieser Wert spiegelt die Konfiguration des Geräts in der Firmware wider. Treiber können es nicht ändern.

Das Abfrageintervall bestimmt zusammen mit der Geschwindigkeit des Geräts und dem Typ des Host-Controllers die Häufigkeit, mit der der Treiber einen Interrupt oder eine isochrone Übertragung einleiten soll. Der Wert in bInterval repräsentiert keine feste Zeitdauer. Dies ist ein relativer Wert, und die tatsächliche Abrufhäufigkeit hängt auch davon ab, ob das Gerät und der USB-Host-Controller mit niedriger, voller oder hoher Geschwindigkeit arbeiten.

- "USB_ENDPOINT_DESCRIPTOR-Struktur" , Hardware Dev Center, Microsoft

Neuere Monitorverbindungsprotokolle wie DisplayPort scheinen dasselbe zu tun:

Multi-Stream-Transport (MST)

  • MST (Multi-Stream Transport) in DisplayPort Ver.1.2 hinzugefügt

    • In Version 1.1a war nur SST (Single-Stream Transport) verfügbar
  • MST transportiert mehrere A/V-Streams über einen einzigen Anschluss

    • Bis zu 63 Streams; nicht "Stream per Lane"

      • Es wurde keine Synchronität zwischen diesen transportierten Strömen angenommen; Ein Stream befindet sich möglicherweise in einer Austastperiode, andere nicht
    • Ein verbindungsorientierter Transport

      • Pfad von einer Stream-Quelle zu einer Ziel-Stream-Senke, die über Nachrichtentransaktionen über AUX CHʼs vor dem Start einer Stream-Übertragung eingerichtet wurde)

      • Hinzufügen/Löschen eines Streams, ohne die verbleibenden Streams zu beeinflussen

(enter image description here

-Rutschen #14 von "DisplayPortTM Ver.1.2 Übersicht" (2010-12-06)

Diese Abstraktion ermöglicht einige nette Funktionen, wie das Ausführen von 3 Monitoren über eine Verbindung:

Der DisplayPort Multi-Stream-Transport ermöglicht auch das Verbinden von drei oder mehr Geräten miteinander, jedoch in der entgegengesetzten, weniger "verbraucherorientierten" Konfiguration: gleichzeitiges Ansteuern mehrerer Displays über einen einzigen Ausgangsport.

- "DisplayPort" , Wikipedia

Konzeptionell ist es wichtig, hiervon abzuweichen, dass Abfragemechanismen eine allgemeinere serielle Kommunikation ermöglichen. Dies ist fantastisch, wenn Sie allgemeinere Funktionen wünschen. Die Hardware und das Betriebssystem führen also viele Abfragen für das logische System durch. Dann können Verbraucher, die Ereignisse abonnieren, diese Details genießen, die vom untergeordneten System für sie verarbeitet werden, ohne ihre eigenen Abruf-/Nachrichtenübermittlungsprotokolle schreiben zu müssen.

Letztendlich scheinen Ereignisse wie das Drücken von Tasten eine ziemlich interessante Reihe von Ereignissen zu durchlaufen, bevor sie zum zwingenden Ereignisauslösemechanismus der Softwareebene gelangen.

19
Nat

Pull vs Push

Es gibt zwei Hauptstrategien, um zu überprüfen, ob ein Ereignis eingetreten ist oder ein bestimmter Status erreicht wurde. Stellen Sie sich zum Beispiel vor, Sie warten auf eine wichtige Lieferung:

  • Pull: Gehen Sie alle 10 Minuten zu Ihrer Mailbox und überprüfen Sie, ob sie zugestellt wurde.
  • Push: Sagen Sie dem Zusteller, er soll Sie anrufen, wenn er die Zustellung erledigt.

Der pull Ansatz (auch Polling genannt) ist einfacher: Sie können ihn ohne spezielle Funktionen implementieren. Auf der anderen Seite ist es oft weniger effizient, da Sie riskieren, zusätzliche Überprüfungen durchzuführen, ohne dass etwas für sie angezeigt wird.

Andererseits ist der Ansatz Push im Allgemeinen effizienter: Ihr Code wird nur ausgeführt, wenn er etwas zu tun hat. Andererseits muss ein Mechanismus vorhanden sein, mit dem Sie einen Hörer/Beobachter/Rückruf registrieren können1.

1  Meinem Postboten fehlt normalerweise leider ein solcher Mechanismus.

8
Matthieu M.

Über die Einheit im Einzelnen - es gibt keine andere Möglichkeit, die Eingabe des Spielers zu überprüfen, als sie in jedem Frame abzufragen. Um einen Ereignis-Listener zu erstellen, benötigen Sie weiterhin ein Objekt wie "Ereignissystem" oder "Ereignismanager", um die Abfrage durchzuführen, sodass das Problem nur an eine andere Klasse übertragen wird.

Zugegeben, sobald Sie einen Event-Manager haben, haben Sie nur eine Klasse, die die Eingabe pro Frame abfragt. Dies bietet jedoch keine offensichtlichen Leistungsvorteile, da diese Klasse jetzt über Listener iterieren und sie aufrufen muss, was abhängig von Ihrem Spiel ist Design (wie in, wie viele Hörer es gibt und wie oft der Player Eingaben verwendet), könnte tatsächlich teurer sein.

Denken Sie außerdem an die goldene Regel - vorzeitige Optimierung ist die Wurzel allen Übels, die insbesondere bei Videospielen gilt, bei denen das Rendern jedes Frames häufig so viel kostet, dass kleine Skriptoptimierungen erforderlich sind solche sind völlig unbedeutend

1
Dunno

Sofern Sie in Ihrem Betriebssystem/Framework keine Unterstützung haben, die Ereignisse wie Tastendruck oder Timerüberlauf oder Nachrichtenankunft behandelt, müssen Sie dieses Ereignis-Listener-Muster ohnehin mithilfe von Polling (irgendwo darunter) implementieren.

Aber lassen Sie sich nicht von diesem Designmuster abwenden, nur weil Sie dort nicht sofort einen Leistungsvorteil haben. Hier sind die Gründe, warum Sie es verwenden sollten, unabhängig davon, ob Sie Unterstützung für die Ereignisbehandlung haben oder nicht.

  1. Der Code sieht sauberer und isolierter aus (bei korrekter Implementierung natürlich)
  2. Der Code, der auf Ereignishandlern basiert, steht besser für Standänderungen (da Sie normalerweise nur einige Ereignishandler ändern).
  3. Wenn Sie zufällig auf die Plattform mit Unterstützung für unterlagerte Ereignisse wechseln, können Sie Ihre vorhandenen Ereignishandler wiederverwenden und einfach den Abrufcode entfernen.

Fazit - Sie hatten das Glück, an der Diskussion teilzunehmen, und haben eine Alternative zur Umfrage gelernt. Suchen Sie nach einer Möglichkeit, dieses Konzept in der Praxis anzuwenden, und Sie werden es zu schätzen wissen, wie elegant der Code sein könnte.

1
OpalApps

Die meisten Ereignisschleifen werden über einem vom Betriebssystem bereitgestellten Polling-Multiplexing-Grundelement erstellt. Unter Linux ist dieses Grundelement häufig der Systemaufruf poll (2) (könnte aber der alte select sein). In GUI-Anwendungen kommuniziert der Anzeigeserver (zB Xorg oder Wayland ) (über einen Socket (7) = oder Pipe (7) ) mit Ihrer Anwendung. Lesen Sie auch über X Window System Protocols and Architecture .

Solche Abfrageprimitive sind effizient; Der Kernel würde in der Praxis Ihren Prozess aufwecken, wenn eine Eingabe erfolgt (und ein Interrupt behandelt wird).

Konkret kommuniziert Ihre Bibliothek Widget Toolkit mit Ihrem Anzeigeserver, wartet auf Nachrichten und sendet diese Nachrichten an Ihre Widgets. Toolkit-Bibliotheken wie Qt oder GTK sind recht komplex (Millionen Zeilen Quellcode). Ihre Tastatur und Maus werden nur vom Anzeigeserverprozess verwaltet (der solche Eingaben in Ereignismeldungen übersetzt, die an Clientanwendungen gesendet werden).

(Ich vereinfache; tatsächlich sind die Dinge viel komplexer)

In einem rein abfragebasierten System muss ein Subsystem, das wissen möchte, wann eine bestimmte Aktion ausgeführt wird, jedes Mal Code ausführen, wenn diese Aktion ausgeführt wird. Wenn es viele Subsysteme gibt, die jeweils innerhalb von 10 ms nach dem Auftreten eines nicht unbedingt eindeutigen Ereignisses reagieren müssten, müssten alle mindestens 100 Mal pro Sekunde prüfen, ob ihr Ereignis aufgetreten ist. Wenn sich diese Subsysteme in unterschiedlichen Thread- (oder schlimmer noch in Prozess-) Prozessen befinden, müsste jeder solche Thread oder Prozess 100x pro Sekunde umgeschaltet werden.

Wenn viele der Dinge, auf die Anwendungen achten, ziemlich ähnlich sind, kann es effizienter sein, ein zentrales Überwachungssubsystem zu haben - möglicherweise tabellengesteuert -, das viele Dinge beobachten und beobachten kann, ob sich eines von ihnen geändert hat. Wenn beispielsweise 32 Switches vorhanden sind, kann eine Plattform alle 32 Switches gleichzeitig in ein Word einlesen, sodass der Monitorcode prüfen kann, ob sich Switches zwischen Abfragen geändert haben und - falls nicht - nicht Sorgen Sie sich, welcher Code an ihnen interessiert sein könnte.

Wenn es viele Subsysteme gibt, die benachrichtigt werden möchten, wenn sich etwas ändert, kann es effizienter sein, wenn ein dediziertes Überwachungssubsystem andere Subsysteme benachrichtigt, wenn Ereignisse auftreten, an denen sie interessiert sind, als wenn jedes Subsystem seine eigenen Ereignisse abfragt. Die Einrichtung eines dedizierten Überwachungssubsystems in Fällen, in denen niemand an Ereignissen interessiert ist, würde jedoch eine reine Ressourcenverschwendung darstellen. Wenn es nur wenige Subsysteme gibt, die an Ereignissen interessiert sind, sind die Kosten für die Überwachung der Ereignisse, an denen sie interessiert sind, möglicherweise geringer als die Kosten für die Einrichtung eines universellen dedizierten Überwachungssubsystems, aber die Gewinnschwelle Punkt wird zwischen verschiedenen Plattformen erheblich variieren.

1
supercat

Ein Ereignis-Listener folgt dem Publish/Subscribe-Muster (als Abonnent)

In seiner einfachsten Form führt ein Veröffentlichungsobjekt eine Liste der Anweisungen der Abonnenten, die ausgeführt werden müssen, wenn etwas veröffentlicht werden muss.

Es wird eine Art subscribe(x) -Methode geben, wobei x davon abhängt, wie der Ereignishandler für die Behandlung des Ereignisses ausgelegt ist. Wenn subscribe (x) aufgerufen wird, wird x zur Liste der Anweisungen/Referenzen der Abonnenten des Herausgebers hinzugefügt.

Der Herausgeber kann die gesamte, einige oder keine Logik zur Behandlung des Ereignisses enthalten. Möglicherweise sind lediglich Verweise auf die Abonnenten erforderlich, um sie mit der angegebenen Logik zu benachrichtigen/zu transformieren, wenn das Ereignis eintritt. Es enthält möglicherweise keine Logik und erfordert Teilnehmerobjekte (Methoden/Ereignis-Listener), die das Ereignis verarbeiten können. Es ist am wahrscheinlichsten, eine Mischung aus beiden zu enthalten.

Wenn ein Ereignis eintritt, iteriert der Herausgeber und führt seine Logik für jedes Element in seiner Liste der Anweisungen/Referenzen der Abonnenten aus.

Unabhängig davon, wie komplex ein Ereignishandler aussieht, folgt er im Kern diesem einfachen Muster.

Beispiele

Für ein Beispiel für einen Ereignis-Listener geben Sie eine Methode/Funktion/Anweisung/Ereignis-Listener für die subscribe () -Methode des Ereignishandlers an. Der Ereignishandler fügt die Methode seiner Liste der Teilnehmerrückrufe hinzu. Wenn ein Ereignis auftritt, durchläuft der Ereignishandler seine Liste und führt jeden Rückruf aus.

Wenn Sie beispielsweise den Newsletter über Stack Exchange abonnieren, wird ein Verweis auf Ihr Profil zu einer Datenbanktabelle mit Abonnenten hinzugefügt. Wenn es Zeit ist, den Newsletter zu veröffentlichen, wird die Referenz verwendet, um eine Vorlage des Newsletters auszufüllen, und sie wird an Ihre E-Mail gesendet. In diesem Fall ist x lediglich eine Referenz auf Sie, und der Herausgeber verfügt über eine Reihe interner Anweisungen, die für alle Abonnenten verwendet werden.

0
Dom

Ein Ereignis-Listener ist wie ein Ohr, das auf eine Nachricht wartet. Wenn das Ereignis eintritt, verwendet die als Ereignis-Listener ausgewählte Unterroutine die Ereignisargumente.

Es gibt immer zwei wichtige Daten: den Moment, in dem das Ereignis eintritt, und das Objekt, in dem dieses Ereignis eintritt. Andere Argumente sind mehr Daten darüber, was passiert ist.

Der Ereignis-Listener gibt die Reaktion darauf an.

0