Skip to content
Eclipse Architecture and Patterns
Überblick
- Wurde zuerst als Framework für IDEs entwickelt
- Dann mit dem Ziel, eine Software-Plattform für allgemeine Desktop-Applikationen zu sein
- Fast alles ist als Plugin implementiert - auch der Workbench (das GUI)
SWT / JFace
- Plattformunabhängig, aber Teil des GUIs ist aber plattform-spezifisch
- SWT selbst entwickelt
- Dünne Abstraktionsschicht über das GUI des Betriebssystems
- JFace baut auf SWT auf und bildet die konkreten und komplexeren GUI-Komponenten
OSGi
- Open Services Gateway initiative
- Komponenten- und Service-Modell für Java + Dependency Management
- Komponenten können gebündelt werden und dynamisch starten / stoppen
- ähnlich zu Java 9 Modularisierung
- Standard, der von Eclipse implementiert wird (mit Equinox)
Eclipse Plug-ins
- Eclipse Plugins sind OSGi bundles
- Plugins können nicht ohne Neustart installiert werden, weil OSGi Services nicht benutzt werden
- Jedes Plugin hat eigenen Class loader, womit mehrere Plugins auch unterschiedliche Versionen einer dependency benutzen können
- Plugins werden erst geladen, wenn es benötigt wird
- Eclipse kann statische XML-Files durchsuchen, ohne dafür Java Code zu laden
Extension Points
- Bsp: Plugin möchte sich in ein Menü einhängen
- Menü bietet einen Extension Point an
- Plugin implementiert Interface des Extension Points
- Plugins können selbst EPs zur Verfügung stellen
- Wird definiert in
plugin.xml
Eclipse Core Patterns
- Viele Singletons - Unit testing unmöglich, ohne eigene Instanz zu starten
- Proxy Pattern: Handler für eine Ressource anbieten, als Abstraktion auf das OS
- Wird auch genutzt für Plugin Lazy Loading
- Plugin wird erst geladen, wenn der Proxy die "action" bekommt
- Pluggable Adapter: Komplexe Komponenten in JFace
- Observer z.B. auf Ressourcen
- Strategy: Ein Teil eines Controls kann verschiedene Arten von Layouts (=Strategies) haben
- Command: JFace Action, z.B. bei einem Klick auf ein Menü
- Sprach-unabhängige API für Refactorings
- Template Method, um Skeleton vorzugeben und bestimmte Schritte an Unterklassen weiter zu geben
- Am Endes des Refactorings wird ein
Change
Objekt erstellt, das vom Eclipse auf die Files angewendet wird
- Ein Change kann aus mehreren Komponenten bestehen -> Composite Pattern
- Refactorings können aus der History exportiert werden, dafür werden sie serialisiert -> Memento Pattern
- Refactorings arbeiten mit dem AST
- Um AST zu traversieren -> Visitor Pattern
- Traversierung ist in den Knoten selbst, nur die benötigten Methoden werden implementiert