nicht angemeldet
Hallo!
Ich muß etwas ausholen, könnte aber etwas kompliziert werden. [...]
Und ich konnte dir kaum folgen.
Ich habe es befürchtet :(
»»Du verwendest ziemlich oft den Begriff Klasse, aber wie mir scheint auch dann, wenn du Objekte meinst. Versuch es verständlich und nachvollziehbar zu beschreiben, denn so kann ich dein Vorhaben nicht bewerten und (alternative) Lösungsvorschläge anbieten.
Ok, noch mal langsam. Es gibt eine Superklasse SK. Es gibt einige Klassen, die von SK ableiten: UK1, UK2 usw. In SK ist eine statische Methode getPlugins($instance) definiert, die von Instanzen von UK1 usw. aufgerufen wird:
$uk1 = new UK1;
In UK1 im Konstruktor:
$this->getPlugins($this);
In SK.getPlugins() findet sowohl der include() als auch die Instanzenbildung
$instance->$newInstance = new $class($instance); statt. Es gibt in SK noch eine andere statische Methode, die zuvor eine Liste mit den vorhandenen Plugins erzeugt. Wie zu sehen, reicht getPlugins() mit new $class($instance) den Zeiger weiter, der sodann in dem Plugin gespeichert wird. $newInstance und $class sind im Prinzip nur bereinigte Namen, vgl. das o. g. Problem mit demselbem Namespace.
Auf die Pluginmethoden läßt sich jetzt mit $uk1->plugin->methode() zugreifen. Im Plugin selbst kann auf Methoden von UK1 zugreifen.
Schöner wäre es, wenn es nicht nötig wäre, Plugininstanzen mit $instance->$newInstance = new $class($instance); zu bilden, sondern einfach die Pluginklasse als statische Klasse direkt in UK1 einzubinden, um dann von außen mit $uk1->pluginmethode() zugreifen zu können.
Erschwerend kommt noch hinzu, daß es mir absolut nicht möglich ist, die Pluginklassen gleich zu benennen. Wenn ich ein Plugin info habe und für drei Unterklassen denselben Klassennamen Info verwenden will, meckert der PHP-Interpreter, er könne sie nicht redeklarieren.
Das ist richtig. Klassen und Funktionen lassen sich unter PHP nicht so schachteln, dass sie lokal bleiben. Sie werden immer im globalen Namensraum abgelegt.
:(
Es ist also nicht eine Kapselung UK1.Info, UK2.Info, UK3.Info usw. möglich, weil die Klassen Info allesamt dem globalen Namensraum angehören.
Meine vorige Aussage löst sich aber grade teilweise in Wohlgefallen auf, denn PHP 5.3 steht vor der Tür und damit auch Namensräume.
Ja, habe ich auch schon gelesen.
Ich denke, damit hat sich die Frage nach einer statischen Einkapselung in andere Klasse erledigt.
Wenn Du aber Vorschläge für eine bessere Architektur hast, sind die auch willkommen.