nicht angemeldet
Hallo!
Wenn jemand ein Plugin schreibt, das auf generische Funktionen zugreifen soll, dann kann man eine Plugin-Elternklasse erstellen, von der dann das Plugin erben kann.
Wenn die Plugins so gestaltet sind, dass sie selbständig nach Dingen suchen, die sie benötigen, baust du eine Zwei-Wege-Abhängigkeit ein, wie sie in der starken Form nicht unbedingt nötig ist. Nicht nur, dass der Handler mit den Plugins umgehen können muss, auch die Plugins sind direkt abhängig von bestimmten Strukturen ihrer Umgebung. Wenn das Plugin sich die DB-Verbindung sucht, und du die mal später ändern willst, rennst du durch alle Plugins und korrigierst den DB-Verbindungssuchmechanismus. Wenn der Handler die Instanz übergibt, behält der die Kontrolle über die DB-Verbindung und das Plugin. Je mehr du etwas mit der Umgebung verzahnst, desto weniger wiederverwendbar sind die einzelnen Teile.
Ja, diese Abhängigkeit sehe ich ja auch. Es sind nun leider mehrere Komponenten der einschachtelnden Instanz, die in den Plugins verwendet werden sollen. Wenn es nun nur um die DB-Verbindung ginge, könnte ich eine eigene Methode zur Herstellung implementieren, in der sich die vorhandene der einbindenden Klasse geholt wird. So könnte man bei Bedarf schnell den Mechanismus zur Herstellung einer DB-Verbindung in der Pluginklasse austauschen, wobei auch hier zunächst mal ein Zeiger auf die einbindende Instanz übergeben werden müßte. Aber es sind nun mal auch sehr essentielle Methoden der einbindenden Klasse, die dem Plugin zur Verfügung stehen sollen. Wenn ich nun noch eine Super-Pluginklasse als Zwischenschicht erstelle, sehe ich nicht, welche Verbesserung das bringen könnte außer einem Anstieg der Bürokratie.
Eine Möglichkeit, die ich hierin erahne, ist, auf die Übergabe der Instanz an die Pluginklasse zu verzichten, indem bei Einbindung des Plugins die Eigenschaften, z. B. die DB-Verbindung, an die Pluginsuperklasse statisch oder eine Instanz von ihr übergeben wird, auf der dann die eigentliche Pluginklasse operieren kann. Ist es das, worauf Du hinauswillst? Was ist aber mit essentiellen Methoden der einschachtelnden Instanz? Die kann ich ja schlecht alle an die Plugin-SK übergeben bzw., was wäre damit gewonnen?
Allerdings ist die Praxis manchmal anders als das Ideal. Wenn das Plugin alles übergeben bekommt, dann ist es in seiner Kreativität eingeschränkt. Greift es zu sehr auf die Umgebung zu, ist es die Beweglichkeit, die darunter leidet. Hier muss man Kompromisse schließen. Beispielsweise wird gern als eine wichtige Eigenschaft einer DB-Abstraktionsschicht angeführt, mit geringstem Aufwand das DBMS wechseln zu können. Doch wann hat man dies nötig? Vermutlich nicht mal in 1% der Fälle. Und wenn man dies vorhat, muss man sich in der Verwendung von Leistungsmerkmalen des DBMS stark einschränken auf das was alle können oder was die DB-Abstraktion generalisiert.
Korrekt, das übliche Postulat zur "reinen" OOP sehe ich auch oft als reinen Selbstzweck an.
Worauf ich hinauswill: Kompromisse sind oft notwendig. Die bestmöglichen zwischen allen Beteiligten zu finden ist nicht einfach aber auch nicht unwichtig.
Das alles ginge natürlich theoretisch, wenn, wie von Dir angeregt, das Plugin selbst von UK erbt.
Nein, ich versuchte anzuregen, es soll von einer Plugin-Klasse erben, nicht von einer Plugin-Handler-Klasse.
Ich fürchte, ich verstehe Dich in diesem Punkt nicht richtig, oder aber es würde nur eine Zwischenschicht ohne wirklichen praktischen Zweck hinzugefügt.
Das Zend Framwork ist zwar nicht das Maß aller Dinge, aber darin steckt viel Erfahrung, von der man gut lernen kann. Das Plugin-System ist dort in der Controller-Komponente untergebracht. Nicht der Controller steuert die Plugins, dafür gibt es den Plugin-Broker. Und der bildet _nicht_ die Basis für die Plugins, dafür existiert die Klasse Zend_Controller_Plugin_Abstract. Allerdings ist das ZF ein Framework für unterschiedliche Aufgaben. Das Plugin-System ist damit auch recht allgemein gehalten. Das Framwork weiß ja nicht, wofür es später mal eingesetzt werden soll, kann also die Plugins nicht mit mehr versorgen als dem Request- und dem Response-Objekt.
Das hört sich auf jeden Fall sehr interesant an. Ich werde mir das in Ruhe anschauen.
Wenn man als Anwender nun seinen Plugins generell DB-Zugriff gewähren will, würde ich das Plugin_Abstract beerben und ihm zumindest eine Eigenschaft für die DB-Instanz hinzufügen. Der Broker bekäme die zusätzliche Aufgabe die DB-Instanz an die Plugins zu übergeben. Und der Controller muss so spezialisert werden, dass er den neuen Plugin-Broker verwendet, was aber mit einem überschriebenen Konstruktor erledigt ist.
Ui, das ist erst mal heftig. Kannst Du das anhand eines fiktiven Beispiels noch mal für mich nachvollziehbarer beschreiben? Das könnte durchaus in die Richtung gehen, die ich brauche.