In and out of Control

Teil 3: Mit Dependency Injection Klassenabhängigkeiten kontrollieren
Kommentare

Das Objekt C würde nur einmal gebildet und bei jedem Gebrauch von C wiederverwendet. Natürlich fehlen einige Features, die die DIC-Implementierungen der großen Frameworks bieten, aber für kleinere Projekte ist Pimple eine ausreichende Alternative.

Zend Framework 2

Listing 8

namespace BsNamespace;


class B
{
  private $a;

  public function __construct(AsNamespaceA $a)
  {
    $this->a = $a;
  }

  ...
}

namespace CsNamespace;

class C
{
  ...
}

namespace AsNamespace;

class A
{
  private $c;  

  public function __construct(CsNamespaceC $c)
  {
    $this->c = $c;
  }
   
  ...
}

...............

$di = new ZendDiDependencyInjector();
$b = $di->newInstance("BsNamespaceB");

Das neue Zend Framework ZF 2 wird an vielen Stellen komplett neu geschrieben und an die aktuellen Möglichkeiten von PHP 5.3 angepasst. Zur Nutzung des DIC von ZF 2 reicht es aus, ähnlich wie im Flow3 Framework, die Typen der zu „injectenden“ Objekte anzugeben. Bei der Instanziierung einer Klasse mithilfe des DIC kann über die Verwendung der Methode des DIC gewählt werden, ob die Instanz immer wieder neu erstellt werden soll oder die Referenz zu einem bestehenden Objekt ausgegeben wird (Listing 8). Die Verwendung eines Dependency-Injection-Containers in einer PHP-Applikation erlaubt die Kapselung der Aufrufe von ihrer Implementierung. Damit ist es zum Beispiel sehr einfach möglich, das Proxy-Pattern einzusetzen und Methodenaufrufe auf Remote-Services abzusetzen, die Response wieder in das erwartete Format zu transformieren und dafür keine aufrufende Stelle im Code anzupassen. Im Symfony2 Framework ist der Dependency-Injection-Container eine so genannte Component. Das bedeutet, dass er unabhängig von Symfony2 eingesetzt werden kann und damit in jedem Projekt genutzt werden könnte. Eine noch einfachere Dependency-Injection-Container-Implementierung ist Pimple, denn es verzichtet auf einige Features, die die Symfony2-Komponente mitbringt, ist aber mit den gebotenen Features oft ausreichend für viele Projekte. In Flow 3 birgt das Object-Framework die Funktionalitäten für die Dependency Injection. Als Besonderheit ermöglichen das Object Framework von Flow3 und der DIC von Symfony2 zusätzlich zu den bekannten Constructor und Setter Injections Property Injection. Dieser Typ der Injection ist prinzipiell das Gleiche wie eine Setter Injection, nur dass kein Setter geschrieben werden muss. Ein Nachteil dieser speziellen Injection-Methode ist, dass eine Property damit maximal „protected“ sein darf.

Der Dependency-Injection-Container des neuen Zend Framework 2 wird anders als der von Symfony2 nicht statisch über eine YAML/XML-Datei konfiguriert, sondern stellt ein PHP API zur Verfügung, mit dem eine dynamische Konfiguration möglich ist. Die Implementierungen der DICs sind im Detail unterschiedlich, aber immer verwendbar. Wirklich spannend sind die Autowiring-Mechanismen, die DIs ohne große Konfiguration erlauben. Aber auch ein einfacher DIC wie Pimple oder die vielen Features des DIC von Symfony2 haben ihre Vorteile. Welcher DIC verwendet werden sollte, hängt sehr stark von den Anforderungen und dem gegebenenfalls schon verwendeten Framework ab.

Fazit

Das Grundprinzip der Dependency Injection ist sehr einfach: Benötigte Objekte werden hineingereicht und können sehr einfach von außen verändert werden. Das erleichtert das Testen und ermöglicht, die Abhängigkeiten explizit zu machen. Der Dependency-Injection-Container ermöglicht die einfache Konfiguration der Abhängigkeiten und die globale Verwendung von Objekten im gesamten Projekt. In großen PHP-Projekten, die auf PHP-Frameworks setzen, sind Dependency-Injection-Container nicht mehr wegzudenken. Aber auch in kleinen PHP-Projekten, die nicht auf ein Framework setzen, kann man überlegen einen DIC einzusetzen. Doch seine Verwendung ist nicht immer sinnvoll: Große Applikationen, die alle Abhängigkeiten über einen DIC auflösen, benötigen unter Umständen komplexe Konfigurationen, die dann auch wieder schlecht zu warten sind. Zur Auflösung von Abhängigkeiten gibt es auch andere Möglichkeiten als einen Dependency-Injection-Container zu nutzen. Wenn man Funktionalität über eine Applikation zur Verfügung stellen möchte, ist die Verwendung eines DIC die richtige Wahl. Wenn „nur“ lokale Abhängigkeiten aufgelöst werden sollen, bieten alle Frameworks gute Alternativen an: Zum Beispiel Annotationen oder den Autowire-Mechanismus. Im Java-Umfeld gibt es einen Standard für DI (JSR-299), der beschreibt wie sie implementiert werden kann. Die DICs der PHP5 Frameworks können prinzipiell das Gleiche, unterscheiden sich aber darin, wie sie verwendet werden und welches API sie bieten.

Nils Langner studierte Informatik an der Universität in Freiburg und ist derzeit beruflich unterwegs als Qualitätsmanager bei Gruner+Jahr, Europas größtem Verlagshaus, das unter anderem Titel wie Stern, Finacial Times Deutschland, Gala und Brigitte beheimatet. In seiner Freizeit betreut er Deutschlands erfolgreichsten PHP-Blog http://www.phphatesme.com, in dem er drei Mal die Woche über Themen aus der Softwaretechnik berichtet.
Mike Lohmann ist Fachinformatiker und seit 13 Jahren in der Webentwicklung tätig. Momentan arbeitet er als Softwarearchitekt bei der ICANS GmbH. Er ist Teil des Netzwerkes werk01 und schreibt gelegentlich für phphatesme.com.
Alle Teile: Teil 1, Teil 2, Teil 3
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -