Umsetzung eines Pluginsystems (I)22 Jul
Die meisten großen freien Anwendung im Web sind heutzutage modular aufgebaut. Modular? Hier beginnt schon der erste Problemaspekt dieser Thematik: Module, Add-Ons oder Plugins? Wo liegt der Unterschied?
Zwischen Modul und Plugin wage ich persönlich keine genaue Differenzierung. Laut Wikipedia ist ein Modul “eine abgeschlossene Komponente einer Software, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen“. Dabei liefert ein Modul ein Ergebnis auf eine Anfrage und kann selbst wiederum Module in sich aufrufen.
Ein Plugin dagegen wird in ein bestehendes System eingeklingt und erweitert oder modifiziert dessen Funktionalität. Add-Ons wiederum sind Erweiterungen eines Systems, die einem bestimmten Muster folgen und dadurch z.B. eine Administrationsoberfläche um einen Bereich erweitern.
Betrachtet man alles zusammen, kann man mit jeder Art und Weise ein bestehendes System verändern – nur auf unterschiedliche Weise.
Trotzdem konzentriere ich mich auf den Namen “Plugin”, da ich nicht nur eine Erweiterung meines Systems will, sondern auch möglichst eine Modifikation des bestehenden Systems.
Zentrale Problematik
Bevor man für seine Anwendung ein Pluginsystem entwickelt, sollte man sich einige Gedanken um folgende Fragen machen:
- Ab welchem Punkt werden Plugins geladen und sind damit einsatzbereit?
- Welcher Form muss ein Plugin entsprechen? Abgeleitete Klasse einer PluginAbstract-Klasse? Oder eine Datei mit bestimmter Namensnotation?
- Was soll ein Plugin beeinflussen können, was nicht?
- Welche Freiheiten sollten dem Plugin gelassen werden?
Ein Plugin sollte sich möglichst an jeder Stelle der Anwendung einklinken können. Damit fällt der Ansatz weg, ein Plugin nur als ein funktional ablaufendes Script einzubinden. Das Plugin soll sich somit in bestimmten Momenten einklinken können – diese “Momente” oder Einsprungpunkte sind sog. Auslöser (trigger) oder Ereignisse (events) – je nach dem, wie man sie nennen möchte.
Wie ist es möglich an jeder Stelle einer Anwendung ein Plugin oder ein Teil eines Plugins auszuführen? Indem die Anwendung keine direkten Funktions- / Methodenaufrufe durchführt, sondern alle Aufrufe über ein “Tor” geschleust werden.
Im Klartext heißt das, dass jede Funktion, die ich in meiner Anwendung verwende, über eine einzige Schnittstelle aufgerufen wird. Diese Schnittstelle muss dann nur noch wissen, welches Plugin ausgeführt werden soll und geht dem nach.
trigger('print', 'Hallo Welt');
Das Beispiel zeigt, wie der Funktion trigger die Strings print und Hallo Welt übergeben werden. Jedes Plugin, das sich nun für die Funktion print “angemeldet” hat, kann nun ausgeführt werden. print ist also sowohl der Funktionsaufruf als auch der Auslösername (trigger).
5 Möglichkeiten eine Funktion zu manipulieren / modifizieren
Es gibt folgende fünf Möglichkeiten eine Funktion durch dieses Prinzip zu manipulieren / modifizieren:
- Pre-Calls
- Post-Calls
- Parametermodifikation
- Funktionsersetzung
- Ergebnismodifikation
Pre-Calls
Hierbei wird eine Funktion vor dem Aufruf der trigger-Funktion ausgeführt.
Post-Call
Als Gegenstück zu Pre-Calls werden bei Post-Calls einfach Funktionen nach der trigger-Funktion aufgerufen.
Parametermodifikation
Damit ein Funktions- oder Methodenaufruf nicht beeinträchtigt wird, muss die trigger-Funktion eine Reihe von Argumenten zulassen. Eines davon ist ein Array mit allen Parametern, die der aufzurufenden trigger-Funktion übergeben werden sollen. Bevor dies geschieht, werden Parametermodifikations-”Plugins” aufgerufen. Diese erhalten die das Argument “Parameter” übergeben und müssen einen entsprechenden Rückgabewert haben. Damit ist es möglich übergebene Parameter zu überprüfen / zu modifizieren.
Funktionsersetzung
Wie der Name schon sagt – in diesem Fall wird die trigger-Funktion durch eine Plugin-Funktion ersetzt. Dies kann logischerweise nur durch eine Funktion geschehen.
Ergebnismodifikation
Als Gegenstück zur Parametermodifikation, erhalten diese Plugin-Funktionen das Ergebnis der trigger-Funktion / Funktionsersetzung zurück. Dieses Ergebnis wurde zunächst in einer Variable gespeichert und wird erst zum Ende von trigger() zurückgegeben.
Diese fünf Möglichkeiten bilden den Kern eines Pluginsystems, das Funktionen oder Methoden hooked. In Teil 2 folgt ein konkretes Anwendungsbeispiel.
Ein sehr schöner Artikel. Ich freue mich echt auf den zweiten Teil. Es kommt mir eigl. sehr gelegen, da ich mich mit einer Plug-in Schnittstelle beschäftigen wollte.
[...] Teil I zu “Umsetzung eines Pluginsystems” wurden theoretische Überlegungen zu einem Pluginsystem angegangen. Die eigentliche Hürde ist [...]
[...] zu genannter Praxis und Umsetzung komme, revidiere ich einen Moment die vorigen Teile I und II. In Teil I bin ich ganz theoretischer Natur auf Plugins eingegangen. Welche Möglichkeiten stecken hinter der [...]