nicht angemeldet
Moin!
Dependency-Injection ist die Methode der Wahl. Dann braucht man auch keine Konfigurations-Singletons.
Gibt es für DI eigentlich ein richtig gutes "Standard-Werk" zum lesen? Ich hab da noch ein paar Lücken beim Verständnis...
Dependency Injection ist das simple Vorgehen, einem Objekt, welches ein anderes Objekt braucht, dieses andere Objekt nicht im Inneren per "new" zu erzeugen, sondern als Parameter über den Konstruktor oder eine Setter-Methode hineinzureichen.
Auf diese Weise kann man außerhalb des Objekts kontrollieren, welches Objekt man hineintut - und kann zum Testen ein passendes Mock-Objekt nehmen, und im Betrieb eines oder eins aus einer Auswahl von mehreren in Frage kommenden Arbeitsobjekten.
Dass die Testbarkeit der Module besser wird ist klar... aber wie wird das ganze konfigurierbar? Momentan sieht es so aus, dass im Live-Betrieb die Objekte mit hardcodierten Abhängigkeiten "injected" werden... das kanns ja nicht sein... wie löst man das elegant?
Die Frage ist immer, wie dynamisch man sowas braucht.
Aber wenn du dir beispielsweise mal Pimple als sehr kleines DI-Framework ansiehst: Das fügt nur relativ geringen Overhead in den Bootstrapping-Prozess ein.
Bootstrapping musst du ja sowieso bei jeder PHP-Applikation machen - selbst dann, wenn du in einer billig top-down programmierten PHP-Seite nur das geringste bißchen weiteren Code requirest, ist das schon eine Art Bootstrapping.
Heutige PHP-Applikationen haben einen relativ einheitlichen Bootstrapping-Prozess:
- Initialisierung des Autoloadings
- Einlesen der Konfiguration
- Konfigurieren des DI-Frameworks*
- Initialisieren der Applikation
- Und am Ende: Abarbeiten des tatsächlichen Requests
Die Konfiguration des DI-Frameworks kann einfach oder kompliziert sein, statisch oder dynamisch - was da genau passiert, ist höchst individuell. Mit Pimple (welches ich bislang noch nicht verwenden konnte) definierst du Lambda-Funktionen, die dir das jeweilige Objekt mit seinen Abhängigkeiten erstellen, wobei die Abhängigkeiten wieder durch Lambda-Funktionen aufgelöst werden, oder durch konfigurierte feste Werte. Diese Kette von Funktionsaufrufen wird aber erst zur Laufzeit ausgeführt, wenn eines der Objekte benötigt wird.
Daraus resultiert logischerweise, dass man am Ende doch irgendeine Art von Gott-Objekt hat, in dem alle diese Abhängigkeiten gespeichert sind. :) Es wird innerhalb der Applikation in einem globalen Kontext erstellt. Aber es wird nicht als statische Klasse betrieben - man könnte sich eine andere DI-Klasse als direkten Ersatz programmieren, wenn man dasselbe Interface implementiert.
DI-Frameworks sind derzeit in der PHP-Welt noch nicht so sehr verbreitet. Beispielsweise im Zend-Framework 1 fehlt es noch an vernünftigem Support, was wohl primär am Support für PHP vor 5.3 liegen dürfte.
- Sven Rautenberg