Plugin-System mit Reflection

Tsa

Mitglied
Hey Leute,
Also ich hab mal nach nem neuen Projekt für mich gesucht und da ich sowas noch nie gemacht habe, wollte ich ein Programm entwerfen, das mit Plugins erweiterbar ist.

Ich hab mich gleich heute Abend dran gesetzt und kam auch soweit, dass Jars geladen und benutzt werden. Erstmal läuft das ganze grafisch ab.
Doch nun würde ich gerne eine Ebene tiefer gehen.

Ich will praktisch, dass das Plugin wirklich mit dem Programm arbeitet, also die Klassen und Methoden des Programms mitbenutzen kann. Weil, was bringt es mir, wenn in einem Programm 10 Programme separat laufen? Ist das so überhaupt möglich? Eventuell so auch gar nicht gewollt?
Hab jetzt zwar viel über Reflections gelesen, aber irgendwie noch keine richtige Antwort gefunden und auch noch keinen Lösungsansatz. Auch hab ich von OSGI, JPF gelesen, die ich mir aber beide noch nicht angeschaut habe (will ja erstmal selbst schauen wie man sowas macht. :) )
Also wäre cool, wenn mir jemand einen Ansatz geben kann oder am besten halt erklären kann wie genau sowas funktioniert! Bin auch offen für Code-Schnipsel. Wenn ichs angewendet sehe, verstehe ichs am besten!

Liebe Grüße,
Jens
 
Ich hab auch noch nix mit Plugins gemacht, aber ich hätte einen anderen Ansatz versucht. Wie bist du auf Reflections gekommen, das macht das Ganze doch nur noch komplizierter...

Ich persönlich versuche meine Programme immer so zu designen, dass das Programm nie alles in einem Modul macht, sondern dass eine Art Zusammenspiel von verschiedenen Modulen entsteht.

Das hat einfach den Sinn, dass man nicht immer direkt in dem Hauptmodul was ändern muss, wenn sich was ändert, sondern nur in dem einen Untermodul. Das Hauptmodul bekommt davon nichts mit und das ist auch gut so. Außerdem könnte man auch theoretisch (oder in vielen Fällen ist es sogar so) das Untermodul gegen ein anderes austauschen. Wenn eine einheitliche Schnittstelle definiert wurde, dann is es ja kein Problem.

Das könnte man auch auf Plugins anwenden, denke ich. Ich stelle mir das ganze so vor, dass man ein Interface definiert, das nennen wir mal Plugin. Das definiert einige Methoden, wie z.B. verarbeiteDaten(Object daten) : Object. Die Plugin-Entwickler müssten dann das Interface Plugin implementieren und damit ergibt sich dann auch, dass die Klasse zwangsläufig die im Interface definierten Methoden implementiert.

Jetzt müssen die Plugins noch dynamisch geladen werden, z.B. über Reflection. Da kommts jetzt aber drauf an, wie man die Plugins speichert. Wenn du das mit JARs machst, dann müsstest du die JAR nach der Plugin-Klasse durchsuchen und diese dann laden.
 
Zuletzt bearbeitet:
Heey,
Danke ihr 2 :)
@Thomas:
Ich hatte zwar keine Zeit das zu testen, aber vom drüber schauen, glaub ich ist es genau das was ich wollte! :)

@Akeshihiro
Japp, soweit war ich :) Und wenn ich dich richtig verstehe, meinst du mit Modularisierung die typische Objektorientierung oder?
Was mir dann hinterher zu schaffen gemacht hat war nach dem laden mit Reflections die Interaktion mit dem "Hauptprogramm".
Beispiel:
Hauptprogramm hat die Methode in der Klasse Verteiler "sendeAnVerbundenenClient(Daten d)".
Hauptprogramm lädt ein Plugin.
Plugin will eine Instanz vom Verteiler erzeugen und die Methode "sendeAnVerbundenenClient(Daten d)" aufrufen. Und das natürlich ohne das das Hauptprogramm eine spezielle Aktion für DIESES plugin vorsieht...
Hoffe du hast verstanden wo mein Problem war. ;) Glaube aber ich komme mit dem Link von Thomas gut weiter!

Liebe Grüße,
Jens
 
Jap, mit Modularisierung meinte ich die Objektorientierung.

Ich schau mir auch ma das von Thomas an, dann hab ich vielleicht einen besseren Ansazt ^^
 
Zurück