nicht angemeldet
echo $begrüßung;
Hier also die Fortsetzung von https://forum.selfhtml.org/?t=177683&m=1170861.
Es gibt eine Superklasse SK.
Welche Aufgabe hat diese?
Dort sind einige wichtige Eigenschaften und Methoden definiert, die für alle UKs gleich sind.
Es gibt einige Klassen, die von SK ableiten: UK1, UK2 usw.
Und wozu dienen diese? [...]
Die UKs sind im Prinzip Verfeinerungen von SK.
Das ist die übliche generische Aufgabe von Super- und abgeleiteten Klassen. Mich hatte eher die Aufgabe aus Geschäftslogik-Sicht interessiert. Meine Vermutungen zu ihrem Tätigkeitsfeld hast du nicht direkt bestätigt oder korrigiert. Ich gehe also davon aus, dass ich damit nicht verkehrt liege.
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.
In den UKs sind halt wichtige Methoden und Eigenschaften wie DB-Verbindungen, die für das Plugin vorhanden sein müssen. Es wäre natürlich klasse, wenn man den Zugriff wie bei der Vererbung mittels protected und private steuern könnte. Als anderes Design könnte ich mir noch vorstellen, Dinge, auf die ein Plugin Zugriff haben soll, als weiteres eingeschachteltes Objekt abzubilden und hierauf einen Zeiger zu übergeben, aber das ändert ja nichts an dem architektonischen Konzept.
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.
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.
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.
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.
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.
echo "$verabschiedung $name";