Plugin basierte GUI

---

Im MVC-Artikel wurde gezeigt, wie auf der Mikroebene model, view und control separiert werden kann. Dieser Abschnitt behandelt ebenfalls ein Separierung von Code, aber aus der Makroperspektive. Stellen Sie sich vor Sie haben eine fertige Anwendung (oder sehen diese in Ihrem Kopf vor sich). Vielleicht können Sie einen Teil der Funktionen der Anwendung restlos streichen, ohne dass alle übrigen Funktionen davon betroffen sind. Wenn das möglich ist sollten Sie darüber nachdenken, diesen Teil als Plugin zu implementieren. Und zwar auch dann, wenn Sie niemals planen Ihre Anwendung ohne dieses Plugin auszuliefern. Mit dieser Strategie zerteilen Sie auf der Makroebene Ihre Anwendung in fachliche und technische Schichten die Sie getrennt voneinander entwickeln und warten können.

Was ist ein 'Plugin'? Als Plugin bezeichne ich eine Softwarekomponente, die von anderen Komponenten gerufen (benutzt) wird, weil sie sich als ein Service an einer dafür vorgesehenen Schnittstelle registriert hat. Die Registrierung ist der entscheidende Unterschied. Eine gewöhnliche Komponente kann von einer anderen Komponente benutzt werden, wenn sie dieser bekannt ist. Es gibt dann unweigerlich Abhängigkeiten von der benutzenden (master, M) zur benutzten (service, S) Komponente.

M --> S

Speziell bei der GUI-Entwicklung gibt es nun das Problem, dass der Service S im allgemeinen bei M viel Wirkung verursacht. Das ist eine umständliche Umschreibung dafür, dass eine GUI im allgemeinen eine hoch interaktive Anwendung sein soll, dass zum Beispiel der Klick auf ein Menüpunkt einen Service S triggert, der als Ergebnis die komplette GUI-Ansicht bei M anpasst. Wir wünschen also eher eine Abhängigkeit in diese Richtung:

M <-- S

Das Problem dabei ist, dass nun M von der Existenz S nichts weiß und S nicht aufrufen kann. Damit das möglich ist muss sich S bei M über von M vorgegebene Schnittstellen registrieren. Mit dieser Strategie lässt sich dann ein System als eine Schichtung aufeinander basierender Services oder Plugins designen.

Für eine Umsetzung dieser Strategie brauchen Sie eine Infrastruktur, die die Registrierung Ihrer aus Services komponierten Anwendung vornimmt. Dafür gibt es verschiedene Ansätze:

• Eclipse bietet eine solche komplette Laufzeit-Infrastruktur (die Eclipse Runtime) und zusätzlich eine Entwicklungsumgebung für eine deklarative Schnittstellendefinition. Die Eclipse Runtime isoliert zur Laufzeit die Services (Plugins) maximal mittels einer ausgefeilten Strategie des Classloadings. Der damit erreichte Grad der Isolierung der Plugins untereinander ist geeignet, komplexe Produkte in sehr heterogenen Entwicklerteams entstehen zu lassen. Eclipse selbst ist das beste Beispiel dafür.
• Wenn Sie den Overhead einer Plugin-zentrierten Entwicklung mit Eclipse vermeiden wollen, können Sie den Einsatz von Spring in Betracht ziehen. Spring ist perfekt dafür geeignet, die Registrierung und Verdrahtung Ihrer Services und Plugins zu übernehmen. Eine saubere technische Trennung der Plugins ist möglich, da, genau wie bei Eclipse, die Registrierung deklarativ erfolgt. Dieser Ansatz eignet sich damit für große und mittlere Projekte und heterogene Teams.
• Als überaus leistungsfähige Infrastruktur für den genannten Zweck sollte auch JMX in Betracht gezogen werden. Allerdings ist der Einsatz im Rahmen einer GUI Entwicklung sicher nur für sehr große Projekte gerechtfertigt.
• Vielleicht können Sie sogar auf jegliches wire up framework verzichten. Bauen Sie einfach alle Plugins und verdrahten Sie sie in der Main-Methode. Damit verlieren Sie zwar die perfekte technische Trennung der Plugins in Ihrer Anwendung, aber Sie finden die Verletzung der Isolierung an einer einzigen, wohl bekannten Stelle. Dieser Ansatz eignet sich für mittlere und kleine Projekte und homogene Teams.

Eine systematische Auflistung der technischen Realisierung von Service-Registrierung habe ich in einem eigenen Dependency Injection Artikel aufgelistet. Hinzufügen möchte ich noch, dass alle Bestrebungen eine Anwendung als eine Komposition von Plugins zu designen zum Scheitern verurteilt sind, wenn aus fachlicher Sicht solche Plugins nicht gibt. Die Anforderungsanalyse muss also eine Schichtung aufeinander aufbauender fachlicher Services benennen.