nicht angemeldet
Tach!
Die Betonung liegt auf ein. Will man ein OOP-PDK anbieten, muss es genau eine abstrakte Plugin-Klasse geben, und über Eigenschaften/Methoden dieser Klasse kommt das Plugin an das API der Basis-Application heran.
Das ist mir schon klar, dass man das Plugin-System so designen kann, dass Plugins eine Basisklasse beerben oder ein Interface implementieren. Aber Vererbung ist für eine Plugin-Technik keine Voraussetzung. Meine Kritik an pl bezog sich auf seine (so von mir verstandene) Aussage, dass man Plugins per Vererbung einbindet. "Du hast eine Basiklasse (Kern) und eine Klassenerweiterung (Plugin) [...]" Da ist nicht die Rede von einer Basisklasse für alle Plugins. Die Basisklasse gehört in seiner Aussage nicht zum Plugin, sondern ist das Gegenstück dazu im Kern. Sowas ist kein Plugin sondern eine Erweiterung des Codes um weitere Funktionalität.
Wenn der Kern zum Beispiel für drei Funktionalitäten braucht, wie spricht er die denn an, wenn er lediglich die Basisklasse kennt? Ich kann mir da nur vorstellen, dass es drei Basisklassen gibt oder eine Basisklasse mit drei speziellen Methoden. Aber wie gesagt, sowas ist nicht das, was ich als Plugin-System bezeichnen würde.
Ein Plugin-System ist für mich im Wesentlichen eine Liste von Hooks, und dazu je eine Liste von Plugins. Diese Liste bildet sich aber erst zur Laufzeit, nachdem das System die zur Verfügung stehenden Plugins gesucht und gefunden hat und die Plugins für die diversen Hooks registriert wurden, für die sie Funktionalität anbieten. Dazu gehört auch, dass für beliebig viele Hooks kein Plugin existiert. In meinem Model ist das Gegenstück zum Plugin der jeweilige Hook. Und dieser Hook ist keine (Basis)klasse sondern ein eine Stelle im Code, die über einen Bezeichner die Pluginverwaltung befragt, ob dafür etwas registriert und auszuführen ist. Da dazu kein Plugin existieren muss, kann der Hook keine abstrakte Basisklasse sein, weil solche ohne implementierende überschreibende Klassen nicht instantiiert werden können.
dedlfix.
Rolf B