Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Plugin Design Patterns in

Ähnliche Präsentationen


Präsentation zum Thema: "Plugin Design Patterns in"—  Präsentation transkript:

1 Plugin Design Patterns in
Eclipse Vortrag im Rahmen des Seminars Software Design Patterns •Unser Vortrag geht um Plugin Architektur allgemein und wie bei Eclipse eine Plugin Architektur umgesetzt wird. •Wir das sind Ronald Kutschke und mein Name ist Markus Block

2 Inhalt Allgemein Plugin
Einleitung Inhalt Allgemein Plugin Vom Starten der Applikation bis zum Benutzen der Plugin Funktionalität Umsetzung bei Eclipse Konzepte in der Plugin Architektur von Eclipse Konzepte Plugin Patterns •Allgemein Plugin •Vom Starten der Applikation bis zum Benutzen der Plugin Funktionalität •Umsetzung in Eclipse •Konzepte in der Plugin Architektur von Eclipse

3 Motivation Ein Programm soll um Funktionen erweitert werden können.
Einleitung Motivation Ein Programm soll um Funktionen erweitert werden können. Diese sind zur Entwicklungszeit des Programms jedoch noch nicht bekannt. •Funktionalität eines Programms soll erweitert werden können. Und zwar um Funktionen, die ich zur Entwicklungszeit des Programms noch nicht kenne. Dadurch gewinnt man Flexibilität und spart Entwicklungskosten bei späteren Erweiterungen, Nachteil sind jedoch höherer Aufwand beim Entwickeln des Plugin Konzepts und geringfügig höhere Performancekosten

4 Allgemein Begriffe Plugin: Software, die ein Programm um Funktionalität erweitert Hostanwendung: Software, die erweiterbar sein soll •Software, die das Programm erweitert: Plugin •Programm das erweitert wird: Hostanwendung

5 Ladevorgang und Zugriff
Allgemein Ladevorgang und Zugriff Starten der Hostanwendung Suchen der Plugins Konfigurationsdatei Festes Verzeichnis Laden und Instanziieren der Plugins Zur Ladezeit der Hostanwendung Wenn Funktion benötigt (Lazy Loading) Nutzen der Funktionalität des Plugins Reflection Callback Interface •Wie sieht ein typischer Ablauf aus, wenn ein Plugin benutzt werden soll? •Als erstes startet die Hostanwendung. Da die Hostanwendung nicht weiss, welche Plugins vorhanden sind, haben wir das erste Problem: Wie findet die Hostanwendung die Plugins? •Über eine Konfigurationsdatei, in die das Plugin bei der Installation seinen Ort im Dateisystem einträgt •Man vereinbart ein festes Verzeichnis und nur die Plugins, die darin abgespeichert sind werden gefunden •Der Ort der Plugins und welche Plugins vorhanden sind ist also bekannt. Dann können die Plugins geladen und instanziiert werden. Hier spielt der Zeitpunkt wann das geschieht eine wichtige Rolle. Zum einen kann ein Plugin geladen und instanziiert werden, sofort nachdem es gefunden wird. Der große Nachteil dabei: Gesamtladezeit der Hostanwendung = Ladezeit der Hostanwendung + Summe der Ladezeiten der einzelnen Plugins. Es gibt eine weitere Möglichkeit und zwar werden die Plugins erst dann geladen, wenn ihre Funktionalität benötigt wird. Das hört sich eigentlich logisch an, man muss aber bedenken, dass oft schon Informationen über das Plugin benötigt werden, bevor man die eigentliche Funktionalität des Plugins benötigt. Zum Beispiel wenn man an ein Menü denkt, dass für jedes Plugin einen Menüeintrag darstellen soll. Wenn man an dieser Stelle die Plugins lädt, hängt das Gui und der Anwender wartet, bis alle Plugin geladen sind. Das hat mich bei PhotoPaint Version 8, dem Bildbearbeitungsprogramm von Corel immer gestört, wenn man aus versehen auf das Menü Effekte geklickt hat, musste man warten, bis alle Plugins geladen waren. Stichwort „Lazy Loading“, dazu später mehr. •Wenn das Plugin geladen ist, dann kann man die Funktionalität nutzen. Das heißt die Hostanwendung wird eine oder mehrere Methoden auf der Pluginklasse aufrufen. Auch hier gibt es zwei Möglichkeiten auf das Plugin zuzugreifen. Erstens: Es gibt eine Vereinbarung oder Absprache über die Signatur der Methoden, d.h. Wie die Methoden aussehen müssen. Das heißt man greift über Reflection auf die Pluginklasse zu. Diese Methode ist etwas umständlich und etwas unperformant. Java bietet uns Interfaces an um diese Vereinbarung programmiertechnisch umzusetzen. Diese heissen in diesem Zusammenhang Callback Interfaces. Sie werden vom der Hostanwendung spezifiziert und müssen vom Plugin implementiert werden.

6 Beispiel 1 Berechnungsklasse Rechenoperationen als Plugins
Beispiele Beispiel 1 Berechnungsklasse Rechenoperationen als Plugins Festes Plugin Verzeichnis Plugins werden zur Ladezeit der Hostanwendung geladen Suchen der Methoden über Reflection •Es gibt ein definiertes Verzeichnis „plugin“, in dem nach Plugins gesucht wird. •Das Laden der Plugins erfolgt zur Ladezeit der Hostanwendung, durch Ausgaben auf die Konsole kann man das gut nachvollziehen •Beim ersten Beispiel gibt es kein Interface, das die Methoden des Plugins beschreibt. Das bedeutet ich greife aus der Hostanwendung über Reflection auf die Methoden des Plugins zu.

7 Beispiel 2 Callback Interfaces anstatt Reflection Beispiele
•Jetzt wird ein Interface für das Plugin definiert. Wie man im Code sieht wird es etwas angenehmer zu programmieren.

8 Beispiele Beispiel 3 Laden der Plugins bei Bedarf der Funktionalität (Lazy Loading)  kürzere Ladezeit der Hostanwendung •Im dritten Beispiel kann man sehen, wie die Ladezeit der Hostanwendung von den Ladezeiten der Plugins entkoppelt wurde und trotzdem Informationen über das Plugin verfügbar sind, um das Menü aufzubauen. Bevor ich die Funktion Plus oder Minus brauche, möchte ich im Menü einen Menüeintrag für jedes Plugin erstellen. Deshalb müssen Informationen über das Plugin in eine Datei ausgelagert werden, damit die Informationen sehr schnell zugänglich sind. Beachtet jetzt die Ladezeit der Hostanwendung. •PluginProxy •Property File

9 Ladevorgang und Zugriff in Eclipse (1)
Umsetzung in Eclipse Ladevorgang und Zugriff in Eclipse (1) Starten von Eclipse Durchsuchen eines festgelegten Verzeichnisses nach Plugins (Eclipse/plugins) •Wie setzt Eclipse nun diese Konzepte um? •Beim Starten von Eclipse wird ein fest vorgegebenes Verzeichnis nämlich „plugins“ durchsucht. Der Plugin Ordner von Eclipse enthält direkt nach der Installation ca 70 Plugins

10 Plugin Verzeichnis (1) ScreenShot Plugin Verzeichnis
Umsetzung in Eclipse Plugin Verzeichnis (1) ScreenShot Plugin Verzeichnis •, ihr braucht nicht nachzählen, es sind wirklich ca 70 Stück, da Eclipse nur aus einem kleinen Kern besteht und fast alle Funktionen in Eclipse als Plugin realisiert sind. Im Bild sieht man auch, dass jedes Plugin ein eigenes Verzeichnis hat.

11 Plugin Verzeichnis (2) Verzeichnis: Eclipse/plugins/org.junit_3.8.1
Umsetzung in Eclipse Plugin Verzeichnis (2) Verzeichnis: Eclipse/plugins/org.junit_3.8.1 junit.jar plugin.xml Icons Weitere Ressourcen •Hier habe ich die wichtigsten Dateien aus dem Junit Plugin dargestellt, das sind junit.jar, hier befinden sich die Klassen gepackt in einem Jar Archiv und die plugin.xml Datei, mit den Informationen über das Plugin, das sogenannte Plugin Manifest.

12 Ladevorgang und Zugriff in Eclipse (2)
Umsetzung in Eclipse Ladevorgang und Zugriff in Eclipse (2) Parsen der Manifest Datei jedes Plugins Aufbau der Plugin Registry Instanziierung über Lazy Loading Zugriff über Callback Interface •Eclipse benötigt daher einen extrem gute Plugin Mechanismus, mit ihm steht und fällt die gesamte Anwendung. Jedes Plugin muss eine Beschreibung in Form einer plugin.xml Datei haben, hier stehen Informationen über das Plugin drin. Anhand aller plugin.xml Dateien baut Eclipse eine Registry auf, über die zur Laufzeit auf diese Plugin Informationen zugegriffen werden kann. •Geladen und Instanziiert werden die Plugins dann wenn sie benötigt werden. Informationen z.B. für das Gui stehen über die plugin.xml zur Verfügung. •Auch die Klasse die Instanziiert werden soll ist in der plugin.xml angegeben. Von der Klasse wird dann der Defaultkonstruktor verwendet. •Zugriff auf die Methoden des Plugins läuft nicht über Reflection, sondern über Callback Interfaces Ronald wird jetzt noch etwas genauer auf die Konzepte eingehen, die im Eclipse Plugin Model verwendet werden.

13 Begriffe in Eclipse Host Extender Plugin Plugin Grundlagen Plugin
Extension Points Extension Member1 Member2 Member3 An Folie: Host kann mehrere EP haben Extender kann EP mehrmals erweitern (Members) (Bsp: Menü) Extender Plugin kann eigene EP bereitstellen Weiter: EP können von mehreren Plugins erweitert werden Extender Plugin kann verschiedene EPs aus verschiedenen Host Plugins erweitern Plugin kann eigene EP erweitern => = Host UND Extender Plugin Wie wird nun EP definiert und wie erweitern man einen EP kann von mehreren Plugin erweitert werden

14 Plugin Manifest Konzepte Extensions Dependencies Identifier
<?xml version="1.0" encoding="UTF-8"?> <plugin id="de.hdm.dp.plugins.helloworld" name="Hello World Plugin" version="1.0.0" class="de.hdm.dp.plugins.example.HelloWorldPlugin"> <requires> <import plugin="org.eclipse.core.resources"/> <import plugin="org.eclipse.ui"/> </requires> <extension point="org.eclipse.ui.actionSets"> <actionSet label="My Action Set„ id="de.hdm.dp.plugins.helloworld.actionSet"> <menu label="My Menu" id="myMenu"> <separator name="myGroup"/> </menu> <action label="My Action" icon="icons/sample.gif" tooltip="Hello, Eclipse world" class="de.hdm.dp.plugins.example.actions.HelloWorldAction" menubarPath="myMenu/myGroup" id="de.hdm.dp.plugins.actions.HelloWorldAction"> </action> </actionSet> </extension> </plugin> Extensions Dependencies Identifier GUI Informationen Konfiguration Extension Point Definitionen Fangen wir hinten an: Wie erweitert man EP Hierzu gibt es das sogenannte Plugin Manifest (=XML Datei (Dateiname plugin.xml)) Benötigt weil: - Plugin aus mehreren Klassen bestehen kann - Plugin mehrere EP erweitern kann (nicht wie im Beispiel von markus) Auszug aus Plugin manifest die den EP Action Sets (Menüs in Eclipse) Erweitert Was steht drin: Extensions -> die Callback Klassen die aufgerufen werden sollen -> man sieht das Member (ActionSet) Dependencies ID, zum referenzieren GUI Infos (wie bei Marlus die Description im Property file) (Labels, Tooltip, Icons, Toolbar und Menubar path -> kann GUI nur aus Manifest Datei aufbauen) -> Vorraussetzung für Lazy Loading später (später genauer) Was man hier nicht sieht: - Konfigurationselemente (so dass man plugin code mehrmals verwenden kann Ihn nur über die XML Datei konfiguriert – Bsp an Markus seinem Plugin) - Definition von EP -> dazu jetzt

15 Definition eines Extension Points
Konzepte Definition eines Extension Points <?xml version="1.0" encoding="UTF-8"?> <plugin id="org.eclipse.ui" name="Eclipse UI" version="2.1.0" provider-name="Eclipse.org" class="org.eclipse.ui.internal.UIPlugin"> <extension-point id="actionSets" name="Action Sets" schema="schema/actionSets.exsd"/> </plugin> Plugin Manifest des Plugin org.eclipse,ui Da wird u.a. der ActionSets EP definiert (nicht extension point sonder extension-point!) Definition steht in exsd Datei

16 Extension Point Schema Definition
Konzepte Extension Point Schema Definition <schema targetNamespace="org.eclipse.ui"> <element name="actionSet"> <complexType> <sequence> <element ref="menu" minOccurs="0" maxOccurs="unbounded"/> <element ref="action" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="id" type="string" use="required"> </attribute> <attribute name="label" type="string" use="required"> </attribute> <attribute name="visible" type="boolean"> </attribute> <attribute name="description" type="string"> </attribute> </complexType> </element> <element name="action"> <choice> <element ref="selection" minOccurs="0" maxOccurs="unbounded"/> <element ref="enablement" minOccurs="0" maxOccurs="1"/> </choice> <attribute name="toolbarPath" type="string"> <attribute name="icon" type="string"> </attribute> <attribute name="tooltip" type="string"> </attribute> <attribute name="class" type="string"> </attribute> </schema> Dies ist actionSets.exsd = XML Schema Definiert nun die Elemente des EP ActoinSets Einzelnen Elemente werden aufgezählt (Datentyp, ob required, wie oft sie vorkommen können) Verschachtelungen… Aus zeitgründen nicht näher eingehen DEMO: Menü einfügen Eclipse bietet standardmäßig Tools: Plugin Development Environment (PDE) - Unterstütz einen beim Editieren des Plugin Manifests - erzeugt Callback Klassen mit benötigten methoden (Callback Interface zeigen!) - beim deployen (jar, zip…) - und entwickeln (run-timeworkbench)

17 Ladevorgang im Detail Konzepte
Aufbau der Plugin Registry beim Start von Eclipse  aus Plugin Manifest Dateien Host Plugin muss beim Aufruf sämtliche Extender Plugins instanziieren  Informationen aus Platform API Aufruf des Default Konstruktors der Callback Klasse eventuelles setzen der Konfigurationsparameter Einmal geladene Plugins bleiben bis zum Beenden von Eclipse aktiv Was geschieht wenn eclipse startet und ein host plugin geladen wird Registry: aus Plugin Manifesten im Plugin Verzeichnis von Eclipse wird Plugin Registry aufgebaut (Baum der Abhängigkeiten darstellt und geparsten XML Dateien enthält) Wenn Host Plugin geladen wird muss es sämtliche Extender Plugin laden um dem User dessen Funktionalitäten zur Verfügung zu stellen (Platform API bietet Zugriff auf Plugin Registry – Klasse „Platform“) Aufruf des Default Konstruktors (es muss einer existieren) Setzen der KonfigParameter (es wird geprüft ob Callback Klasse bestimmtes Interface implentiert, wenn ja wird im Interface festgelegte Methode mit den KonfigParametern aufgerufen) Plugins werden nicht wieder deaktiviert sondern bleiben aktiv (bis Eclipse geschlossen wird)

18 Lazy Loading Konzepte Problem:
Rekursive Instanziierung aller Callback Klassen  zeitaufwändig Lösung: Instanziieren „leichter“ Dummy Objekte  instanziieren bei Bedarf eigentlichen Callback Objekte  leiten Aufrufe an Callback Objekte weiter Auslagern der GUI Informationen in Plugin Manifest Vorher gezeigte Ablauf würde das Instanziieren sämtlicher Callback Klassen zu Folge haben (Plugin besteht meistens aus mehreren Extensions, die wiederum mehrmals erweitern werden So gibt es also noch mehr Extension Members und jedes hat eigenes Callback Objekt -> es kann ziemlich viele Callback Klassen geben, die auch wieder eigene Klassen instaniieren) -> LANGSAM (Start, im Programm und viel Arbeitsspeicher) Dummy Objekte, die wissen wie Callback Objekt zu instanziieren ist (Infos aus Plugin Manifest) und die Aufrufe vom Client an das Callback Objekt weiterleiten -> Objekt kann nicht mehr nach GUI Infos (Label…) für die Darstellung gefragt werden GUI muss aber aufgebaut werden -> auslagern in Plugin Manifest Was für ein Pattern ist das? Proxy!!!

19 Lazy Loading – Virtual Proxy
Konzepte Lazy Loading – Virtual Proxy Host Plugin Extender Plugin Proxy implementiert das im Host Plugin spezifizierte Callback Interface und wird beim laden statt MyCallback instanziiert Es weiss wie MyCallback zu erzeugen ist (Klassenname) und tut dies beim ersten Aufruf von run() Es leitet dann alle Aufrufe von run an MyCallback weiter Hier: Proxy und MyCallback implementieren das selbe Interface Eclipse kennt dieses Interface aber nicht (kein automatisiertes Lazy Loading) -> jedes Plugin muss Lazy Loading selbst implementieren ->Virtual Adapter Pattern instantiates

20 Lazy Loading – Virtual Adapter
Konzepte Lazy Loading – Virtual Adapter Eclipse Host Plugin Extender Plugin Eclipse stellt zwei unabhängige Interfaces IAction und IActionDelegate zur Verfügung IAction muss vom Host Plugin implementiert werden (neben run() müssen Methoden implementiert werden die beim Aufruf der Action vom User gesetzt werden (Übergabeparameter)), IActionDelegate von Extender Callback Klasse VirtualAdapter instanziiert MyCallback beim ersten Aufruf von run() und adaptiert die IAction.run() Methode zu der von IActionDelegate dabei übergibt er sich selbst als Parameter Wodurch das MyCallback Objekt Zugriff auf die Action Übergabeparameter bekommt Durch diesen Mechanismus kann das Lazy Loading komplett automatisiert von Eclipse Übernommen werden, da Eclipse die speziellen Callback Klassen der Plugins nicht kennen muss (Host und Extender Klassen müssen nur die entsprechenden Interfaces implementieren) Anmerkung: Es gibt in Wirklichkeit noch eine Zwischenschicht mit vordefinierten abstrakten Klassen, für den jeweiligen Anwendungszweck. Diese implementieren schon einmal Grundfunktionalitäten wie z.B. das Laden der Klassen über Reflektion. Der eigene VirtualAdapter des Host Plugins braucht die instanziierte Klasse dann nur noch auf MyCallback zu casten instantiates

21 Service Extension Pattern
Konzepte Service Extension Pattern Ein Event im Host Plugin bewirkt das Aufrufen von einem Callback Objekt eines Extender Plugins Extender Plugin 1 Host Plugin Event1 Normales vorgehen von Host Plugins: jede Erweiterung separat einzubinden wie die ganze Zeit besprochen Bsp: Wenn man auf ein MenuItem klickt ruft das ein Callback Objekt auf Extender Plugin 2

22 Listener Extension Pattern (1)
Konzepte Listener Extension Pattern (1) Art des Observer Patterns Registrierung als Listener/Observer für ein bestimmtes Event bei einem Host Plugin Registrierung über das Erweitern eines Extension Points des Host Plugins Callback Interface entspricht Observer Interface im Observer Pattern Zusätzlich zum Service Extension Pattern gibt es noch ein anderes Verhalten wie Host Plugins mit der Erweiterung ihrer Extension Points Verfahren können Und zwar registriert man sich durch das Erweitern eines Extension Points als Listener für ein Event beim Host Plugin und wird immer dann benachrichtigt wenn dieses Event auftritt

23 Listener Extension Pattern (2)
Konzepte Listener Extension Pattern (2) Ein Event im Host Plugin bewirkt das Aufrufen sämtlicher Callback Objekte der registrierten Extender Plugins Extender Plugin 1 Host Plugin Member 1 Member 2 Event Das Bedeutet tritt das Event am Host Plugin ein informiert dieses jedes Callback Objekt der registrierten Listener Da ein Extender Plugin ein Extension Point auch mehrmals erweitern kann, kann ein Plugin auch mehrere Listener registrieren Beispiel: JUnit erlaubt das Registrieren von Listenern um bei bestimmten Events (wie z.B. das Beginnen oder Ende eines Tests) benachrichtigt zu werden Extender Plugin 2

24 Fazit Heutige Programme kommen an einem Plugin Konzept nicht vorbei.
Eclipse stellt durch seine flexiblen Erweiterungs-möglichkeiten ein sehr mächtiges Plugin Konzept zur Verfügung, das wesentlicher Bestandteil des Erfolges der Eclipse IDE ist.

25 Quellen Notes on the Eclipse Plug-in Architecture (Azad Bolour) Eclipse Platform Technical Overview (Object Technology International, Inc.)

26 Fragen Fragen zum Thema?


Herunterladen ppt "Plugin Design Patterns in"

Ähnliche Präsentationen


Google-Anzeigen