Artikelformat

Event Collaboration Pattern

Nachdem ich im letzten Beitrag ein sehr bekanntes Pattern angesprochen habe und dies auch mit einigen Kommentaren gewürdigt wurde, möchte ich heute ein etwas anderes Pattern vorstellen. Dabei handelt es sich um das Event Collaboration Pattern. GWT-Entwickler werden dieses Pattern kennen, in der PHP Welt kenne ich nur eine ähnliche Implementierung.

Man nutzt diese Pattern um Komponenten lose zu koppeln und auf bestimmte Ereignisse im Gesamtsystem nur noch reagieren zu lassen. Jede Komponente muss natürlich die eigenen Änderungen weitergeben, damit das alles auch funktioniert.
Um die Kommunikation zu ermöglichen, gibt es Events. Diese kapseln die Informationen und reichen sie an entsprechende EventHandler weiter. Dieses Verhalten ist aus der Event-getriebenen Programmierung bekannt. Die Besonderheit ist nun beim Event Collaboration Pattern, dass man Sender und Empfänger der Events gegeneinander abschottet, indem man einen EventBus einsetzt.
Die Sender müssen Zugang zu diesem EventBus haben, was man bspw. durch Dependency Injection oder ein Singleton realisieren kann. An diesem EventBus registrieren die Empfänger ihre EventHandler. Somit kennen beide Parteien den anderen nicht und sind nur vom EventBus abhängig. Weiter gibt der EventBus ein empfangenes Event an alle Handler weiter, die sich für dieses Event registriert haben. Somit kann ein Event auch mehrere Aktionen anstoßen.
In der Beschreibung von Martin Fowler wird das Command Pattern genutzt, um die Handler zu realisieren. Da wir uns in der PHP-Welt bewegen, kann man dies auch gerne überspringen und stattdessen Callbacks nutzen.
Bei diesem Pattern kann man in eine sehr fiese Falle laufen: Events lassen sich auch kaskadieren, was bedeutet, das ein Event gefeuert wird, ein Handler dieses Event verarbeitet und seinerseits ein neues Event feuert. Das Verfahren ist normalerweise unproblematisch, außer man läuft in einen Zyklus. Wie man sich vorstellen kann, hängt man dann in einer Endlosschleife fest. Dies zu entdecken könnte sich als schwierig herausstellen und man sollte hier die Events wirklich mit Bedacht einsetzen.

3 Kommentare

  1. Mir war bislang nicht bewusst, dass es ein eigenes Pattern ist, ich hätte es wohl unter Observer/Listener eingeordnet. Wie auch immer. Aus eigener Erfahrung kann ich sagen, dass es eine sehr angenehme Art zu Programmieren ist, da man in Ruhe seine Komponenten schreiben kann und denen nur mitteilen muss, worauf sie im System hören sollen. Selbst wenn man keine Frameworks nutzt, ist das Prinzip relativ einfach umzusetzen. Zu der möglichen Endlosschleife: Das kann auch bei prozeduraler Programmierung passieren, wenn man nicht aufpasst.

    Antworten
  2. Hey, wirklich ein schöner Beitrag.

    Zur Zyklenverhinderung ist doch sicher ein Algorithmus beim Hinzufügen denkbar, der automatisch Zyklen identifiziert und in diesem Fall eine Exception auslöst, dann wäre das Problem auch gelöst?

    Ich der Aufwand wäre sicher gerechtfertigt und wenn man nach dem Standard-Verfahren für solche Fälle vorgeht, sollte das keine große Sache sein.

    Antworten
  3. Übrigens hat Eventorientierung immer das Problem, dass „einfache“ Fälle zwar gut und elegant abzudecken sind, komplexe Bedingungen mit vielen Variablen aber zu Schwierigkeiten führen können, insbesondere wenn sich Zustände häufig in „verschiedene Richtungen“ ändern, von denen ein Event abhängig ist.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.