Vom 27.01.2012 bis zum 28.01.2012 findet in Antwerpen die PHPBenelux Konferenz statt. Ich freue mich mit dem Vortag “The state of DI in PHP” als Sprecher dabei sein zu dürfen. Neben vielen interessanten Vorträgen werden Workshops mit Matthew Weier O’Phinney, Ivo Jansch, Fabien Potencier und Thorsten Rinne angeboten. Der Early Bird Kartenvorverkauf läuft zur Zeit noch, so dass Karten recht günstig zu erwerben sind.

After reading an blog post about a Dependency Injection container in PHP I just tweeted for curiosity why PHP developers have not yet agreed on a common standard for the behaviour of an DI container. Stefan Koopmanschap jumped into the discussion and proposed I should start a movement in this particular area. He suggested that Fabien Potencier (Symfony Lead Developer) as well as David Zülke (Chief Agavi fanboy) and Matthew Weier O’Phinney (Zend Framework lead developer) should team up with me. David got hooked immediately and I am looking forward to meet the gang at phpDay.it in Verona for the first round of discussions. In case you want to contribute as well feel free to join us or blog about this movement

Dank Robert Lemke vom Typo3 Projekt gibt es seit einigen Tagen einen RFC für sog. Custom Factories für PHP. Die grundsätzliche Idee des RFC ist es via SPL die Objekterzeugung beeinflussen zu können, ähnlich wie es bsp. mit spl_autoload möglich ist eigene Klassenloader zu definieren. Er möchte damit Einschränkungen in Legacy Bibliotheken aufbrechen die es aufgrund von fest verdrahteten Abhängigkeiten nicht möglich machen eigene Komponenten innerhalb der Legacy Bibliothek zu verwenden. Im aufgeführten Beispiel wird dies gut anhand eines Logger-Beispiels aufgezeigt. Im Grunde halte ich die Idee für recht interessant. Ich denke viele Entwickler sind in der Vergangenheit über das Problem gestoßen dass sich Frameworks oder Bibliotheken von Drittanbietern an machen Stellen nicht optimal in die eigenen Anwendungsstrukturen einbinden lassen konnten bzw. es nur sehr umständlich möglich war eine Integration zu erreichen.

Etwas verwundert bin ich allerdings über die Beispiele mit der ObjectFactory, so schreibt er “If the mechanism of Dependency Injection is consequently used, this results in a lot of additional typing and many classes will need the ObjectFactory getting injected by the surrounding framework” . Dem kann ich leider nicht zustimmen. Das verwendete Framework sollte dem Entwickler alle Injection-Arbeiten abnehmen und statt der ObjectFactory die notwendigen Referenzen auf die real benötigen Klassen übergeben. Der Domaincode sollte m.E. so gut wie frei von Abhängigkeiten zu Frameworkklassen sein. Ich möchte weder in meinem Programmcode Objekte mit dem new Operator erzeugen noch abhängig zu Factories sein die das ganze für mich erledigen. Des weiteren halte ich es für extrem wichtig die Objektkonfiguration von der Implementierung zu trennen, denn nur so erreicht man eine maximal mögliche Wiederverwendung. Annotations im Programmcode oder das automatische Finden der Abhängigkeiten anhand von implementierten Interfaces scheint mir keine sinnvolle Umsetzung von DI zu sein.

In den letzten Monaten wurden in einigen Blogs immer mal wieder Beiträge zum Thema Dependency Injection (DI) in PHP verfasst. In einem aktuellen Beitrag von Fabien Potencier, dem Lead-Entwickler von Symfony, stellt er die These auf dass man mitunter keinen IoC Container benötigt um grundsätzlich vom DI Ansatz zu profitieren. Diese Ansicht kann ich nicht teilen. Aus seinem Beispiel und auch den Beispielen aller anderen Blogbeiträge wird der Nutzen von DI, vor allem im Rahmen eines kompletten Frameworks, meines Erachtens nicht klar genug dargestellt. Das Thema ist natürlich viel zu komplex um in einem kurzen Blogeintrag behandelt zu werden. Die Vorteile von DI sind schließlich vielfältiger Natur. Zu erkennen wie sauber der eigene Programmcode werden kann, wie einfach sich die einzelnen Schichten einer Anwendung testen lassen oder was die Austauschbarkeit einzelner Komponenten zur Laufzeit bedeutet, braucht seine Zeit. Das zeigt zumindest meine Erfahrung aus den letzten drei Jahren täglicher Arbeit mit DI mit unserem bitFramework.