Apache Zeta Components: Der SignalSlot
Kommentare

Modularisierung und Erweiterbarkeit von Webapplikationen ist kein einfaches Thema und es gibt verschiedenste Ansätze der Umsetzung. In objektorientierten Applikationen kommt einem wahrscheinlich als erstes

Modularisierung und Erweiterbarkeit von Webapplikationen ist kein einfaches Thema und es gibt verschiedenste Ansätze der Umsetzung. In objektorientierten Applikationen kommt einem wahrscheinlich als erstes das Ableiten von existierenden Klassen in den Sinn, um sie mit eigenem Verhalten zu erweitern. Doch das kann nicht nur leicht mit objektorientierten Prinzipien brechen (wie dem Liskov substitution principle), sondern verursacht oft auch, dass nur ein Modul oder eine Erweiterung eine existierende Klasse erweitern kann. Wenn mehr als ein Modul existierende Klassen anpassen will, ist die Ableitungsreihenfolge nicht mehr klar spezifiziert.

Für solche Erweiterungen haben sich alternative Pattern durchgesetzt. Sie informieren Module von Ereignissen im System, so dass diese darauf reagieren können. Aggregation, Hooks, Subject-Observer und SignalSlot sind nur einige davon – sie alle haben ihre Vor- und Nachteile. An dieser Stelle möchte ich nun etwas Licht auf die SignalSlot-Komponente aus den werfen. SignalSlot ist, meiner Meinung nach, ein häufig sinnvolles Pattern, um Software-Module voneinander zu entkoppeln, sodass sie aber trotzdem noch auf gegenseitige Ereignisse reagieren können.

Ein vollständiges Tutorial zur SignalSlot-Komponente findet sich natürlich online, sodass ich mich hier auf ein kurzes illustratives Beispiel beschränken kann. Das Prinzip ist relativ einfach: Es gibt (mindestens) einen zentralen SignalSlot Handler, der die Signal verwaltet. Module können sich für einzelne Signal bei ihm registrieren, und andere Module können wiederum Signale „emittieren“ (abfeuern).

$handler = new ezcSignalCollection(); 
$handler->connect( "sayHello", array( "myModule", "hello" ) ); 
$handler->emit( "sayHello" );  

Zuerst wird im Beispiel der zentrale Handler instantiiert, auf dem sich dann beliebige Module für Signale registrieren können – Signale werden normalerweise durch einfache Strings identifiziert. In diesem Fall registriert sich in Zeile 2 ein Modul mit einem Callback auf die Methode hello() in der Klasse myModule. Weitere Module können sich für das gleiche Signal registrieren. Später wird dann woanders im Code ein Signal ausgelöst. Optional können dem Signal noch Parameter mitgegeben werden.

Der Charme von SignalSlot ist nun, dass das emittierende Modul nicht wissen muss, wie viele Module oder wer sich an ein Signal gekoppelt hat. Für entscheidende Ereignisse in einem System werden Signale gefeuert und beliebige Komponenten können sich anhängen. Der SignalSlot Handler übernimmt die Verantwortung für die Ausführung aller registrierten Callbacks – hier sollte man sich nicht auf eine Reihenfolge verlassen. Diese Unabhängigkeit kann dann aber zu einem Problem werden, weil der aufrufende Code nicht wissen kann, wie lange die Abarbeitung eines Signals brauchen wird.

Ein klassisches Ereignis, das das Feuern eines Signals verursacht, ist die Registrierung eines Benutzers. Ein anderes Modul könnte dann zum Beispiel einen Kontostand für diesen Benutzer initialisieren. Signale haben grundsätzlich natürlich keine Rückgaben, jedoch kann der getriggerte Code wiederum ein Signal emittieren. Gerade in Kombination mit Workflow-Systemen oder vielen optionalen Modulen ergibt SignalSlot oft Sinn.

Kore Nordmann

Kore Nordmann arbeitet seit mehr als 10 Jahren in professionellen Webprojekten auf Basis von PHP. Als Open-Source-Enthusiast beteiligt er sich an verschiedensten Communityprojekten. Kore ist Mitgründer der Qafoo GmbH, die Services rund um hochqualitative PHP-Entwicklung anbietet, sowie Consulting, Training und Support zu Apache Zeta Components.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -