Normal
@tröööötDu hast das falsch verstanden. Ich meinte, dass wenn man eine abstrakte Klasse als Basisklasse für Plugins nimmt und sich daran irgendwas ändert, dann sind die Plugins mit der neuen Version der Anwendung nutzlos, weil dann keiner mehr garantieren kann, wie sich das Plugin dann noch verhält bzw. ob die Schnittstellen überhaupt noch passen. Daher bekommt der Pluginprogrammierer eben nur die Interfaces, die er für seine Plugins braucht und das wars.Die Verwaltung der Configs kann die Anwendung locker übernehmen. Die Plugins bekommen dann eben beim Laden nur die Properties oder was auch immer und beim Speichern wird das auch nur mit Properties gehandhabt. Wie das Speichern dann aussieht, soll doch die Anwendung selbst machen (Datei, DB, ...). Aber gut, so hat jeder seine eigene Vorstellung von solchen Architekturen ...@oOJavaNeulingOoDas ist einfach. Mach deine Klasse Pl abstrakt, dann brauchst du die Methode da nicht nochmal leer implementieren.
@trööööt
Du hast das falsch verstanden. Ich meinte, dass wenn man eine abstrakte Klasse als Basisklasse für Plugins nimmt und sich daran irgendwas ändert, dann sind die Plugins mit der neuen Version der Anwendung nutzlos, weil dann keiner mehr garantieren kann, wie sich das Plugin dann noch verhält bzw. ob die Schnittstellen überhaupt noch passen. Daher bekommt der Pluginprogrammierer eben nur die Interfaces, die er für seine Plugins braucht und das wars.
Die Verwaltung der Configs kann die Anwendung locker übernehmen. Die Plugins bekommen dann eben beim Laden nur die Properties oder was auch immer und beim Speichern wird das auch nur mit Properties gehandhabt. Wie das Speichern dann aussieht, soll doch die Anwendung selbst machen (Datei, DB, ...). Aber gut, so hat jeder seine eigene Vorstellung von solchen Architekturen ...
@oOJavaNeulingOo
Das ist einfach. Mach deine Klasse Pl abstrakt, dann brauchst du die Methode da nicht nochmal leer implementieren.