Inversion of Control

Lesetipps

1. Inversion of Control – Teil 2
2. Dependency-Injection ist nicht Inversion-of-Control
3. Inversion of Control – Teil 3

Viele haben sicher schon einmal etwas von Inversion of Control (IoC) und Dependency Injection (DI) gehört. Und sicher auch, dass es ganz toll ist und es zu den best practices gehört. Nur eine Frage die oft nicht wirklich beantwortet wird: Wieso ist das so sinnvoll?

Ich versuche hier einmal diese Frage mit einem Beispiel aus dem realen Leben zu dokumentieren und zu beantworten…

Wir stellen uns eine größere mittelständige Firma vor. Sie hat mehrere  Abteilungen die eigenständig arbeiten. Natürlich müssen da auch Dinge angeschafft werden und das kostet Geld. Entsprechend ihrem Bedarf bestellen diese Abteilungen also Dinge wie Drucker, Computer oder Spezialhardware. Die Rechnungen werden in die Buchhaltung gegeben und dann von dort aus bezahlt.

Das KANN alles super funktionieren. Aber nur dann, wenn diese Abteilungen auch verantwortungsbewusst mit Geld umgehen und nur Dinge anschaffen, die sie wirklich benötigen. Außerdem ist es schwer einen Abteilungsübergreifenden Überblick zu bekommen, welche Hardware vorhanden ist. Es kann auch passieren, dass mehrere Abteilungen die selbe Spezialhardware bestellen obwohl sie sich diese eigentlich hätten teilen können. Auch ist es schwer nachzuvollziehen wo denn das ganze Geld geblieben ist.

Wie kann man diesen Zustand also optimieren? So wie es in der Praxis oft gehandhabt wird: Die Abteilungen melden am Anfang eines Jahres ihren Bedarf an, daraus wird ein Gesamtbedarf ermittelt und ein Jahresbudget errechnet. Das wird dann angepasst und optimiert und jeder Abteilung ein Budget, welches sie zur Verfügung haben, mitgeteilt. Größere Anschaffungen müssen jedoch erst genehmigt werden (damit kann man doppelte Einkäufe teurer Spezialhardware vermeiden). Und da diese größeren Anschaffungen nur

noch von einer zentralen Stelle vorgenommen werden hat man darüber auch immer einen Überblick.

Und Dinge die sich so im Alltag bewährt haben machen auch beim Softwaredesign Sinn. Wieso soll sich eine Klasse Gedanken machen woher sie ihren Logger bekommt? Oder wo sie einen Zugang zur Datenbank findet? Das ist gar nicht ihre Aufgabe. Es ist viel sinnvoller einer Klasse einfach einen Logger oder eine Datenbankverbindung an die Hand zu geben und sie macht das was sie am besten kann. Ihre eigene Logik zu implementieren.

Soweit die graue Theorie. Ich hoffe ich habe nun alle (oder zumindest viele) von dem Nutzen der IOC und DI überzeugen können. Denn nun möchte ich zeigen, wie die Umsetzung dessen in der Praxis aussehen kann.

Hier der bisher unschöne Weg wie eine Klasse Ressourcen verwendet:

 class MyClass { private $_logger; private $_dbHandle; 

 function __constructor() { $this->_logger = Zend_Registry::get('LOGGER'); $this->_dbHandle = Zend_Registry::get('DB'); } function doSomething() { // etwas loggen $this->_logger->write('foo');  

 // Daten aus der Datenbank lesen $this->_dbHandle->select('SELECT * FROM bar'); } } 

Die Klasse holt sich im Konstruktor selber ihre Abhängigkeiten und verwendet sie dann.

Besser ist folgender Ansatz:

 class MyClass { private $_logger; private $_dbHandle; function __constructor() { } function setLogger(Zend_Log_Writer_Abstract $logger) { $this->_logger = $logger; } function setDbHandle(Zend_Db_Adapter_Abstract $dbHandle) { $this->_dbHandle = $dbHandle; } function doSomething() { // etwas loggen $this->_logger->write('foo'); // Daten aus der Datenbank lesen $this->_dbHandle->select('SELECT * FROM bar'); } } 

Die Klasse bekommt ihre Abhängigkeiten über Setter-Funktionen gesetzt. Man kann an dieser Stelle die Setter natürlich auch zugunsten von Konstruktor-Parametern ersetzen. Ein offensichtlicher Vorteil ist schon einmal, dass die Klasse sich nicht überlegen muss WOHER sie den Logger oder das DB-Handle bekommt. Der Zugriff über eine Registry ist nichts weiter als eine objektorientierte Form von globalen Variablen. Wenn sich der Zugriffsbezeichner ändert, müssen alle Klassen angepasst werden. Ebenso ist der Rückgabewert einer solchen Registry nicht Typsicher. Dieses Problem haben wir über die Setter-Funktionen gelöst.

Soweit möchte ich hier erst einmal Schluss machen für diesen Artikel. Im nächsten Artikel möchte ich dann einmal zeigen, wie man sehr einfach diese Dependency Injection umsetzen kann.

25 Kommentare »

• 
  

  Christian

  am 27. Mai 2010 um 07:14 Uhr

  Ist Zend_Registry dem Symfony Dependency Injection Container vorzuziehen? Wo liegen die Vorteile bzw. Nachteile?

• 
  

  Daniel

  am 27. Mai 2010 um 07:19 Uhr

  Abgesehen von den bereits beschriebenen Vorteilen wird auch das Testen einfacher werden, wenn die Abhängigkeiten nicht fest verankert sind und später gegen Dummies getauscht werden können.

• 
  

  ragtek

  am 27. Mai 2010 um 07:45 Uhr

  Die Klasse bekommt ihre Abhängigkeiten über Setter-Funktionen gesetzt. Man kann an dieser Stelle die Setter natürlich auch zugunsten von Konstruktor-Parametern ersetzen.

  Ist sowas damit gemeint:

  public function __construct(vB_Registry $vbulletin, vB_Database $osdb = null)
  {
  $this->registry = $vbulletin;
  if ($osdb == null)
  {
  $this->osdb = $this->registry->db;
  }
  else
  {
  $this->osdb = $osdb;
  }
  }

• 
  

  Sven

  am 27. Mai 2010 um 08:47 Uhr

  @ragtek Ja so in der Art. Ich weiß jetzt nicht genau was die vB_Registry macht, aber an sich soll auf eine Registry möglichst komplett verzichtet werden. Weil in deinem Beispiel holt er sich ja wieder das DB-Handle aus einer Registry, was ja vermieden werden soll. Aber Grundsätzlich ist der Ansatz so wie du ihn gepostet hast. Für Mein Beispiel sähe das so aus:

  class MyClass
  {
  private $_logger;
  private $_dbHandle;

  function __constructor(Zend_Log_Writer_Abstract $logger,
  Zend_Db_Adapter_Abstract $dbHandle)
  {
  $this->_logger = $logger;
  $this->_dbHandle = $dbHandle;
  }

  function doSomething()
  {
  // etwas loggen
  $this->_logger->write(‘foo’);

  // Daten aus der Datenbank lesen
  $this->_dbHandle->select(‘SELECT * FROM bar’);
  }
  }

• 
  

  Tyler

  am 27. Mai 2010 um 09:26 Uhr

  @Christian

  Ich würde den Symfony Dependency Injection Container vorziehen, es gibt auch einen schönen Artikel wie man ihn in Zend einbauen kann

  http://www.whitewashing.de/blog/articles/118#comments

  Die Konfiguration des kannst Symfony Dependency Injection Container du dann z.B. über XML Dateien vornehmen

  http://components.symfony-project.org/dependency-injection/trunk/book/B-XML-Format

• 
  

  Thomas

  am 27. Mai 2010 um 10:51 Uhr

  Hi,

  Nachteile der gezeigten Methode (via Setter statt Parameter im Constructor):

  - Das Objekt ist nicht direkt nutzbar nach Aufruf des Constructors, sondern Setter müssen noch aufgerufen werden.

  - Ich muss in der Doku nachschauen, wie ich das Objekt korrekt initialisiere. Das sagt mir auch keine Code-Completion einer IDE.

  Da gibt es verschiedene Möglichkeiten (deren Vor- und Nachteile ich hier nicht ausführe):

  - Dem Constructor müssen die Objekte mitgegeben werden.

  - Der Constructor erzeugt Standard-Objekte (für Logger & Co); diese können mit Settern verändert werden.

  - Man arbeitet nicht mit $this->logger, sondern mit $this->getLogger() und falls der User keinen Logger mit einem Setter gesetzt hat, wird ein Standard-Objekt erzeugt.

  Schöne Grüße

  Thomas

• 
  

  jonas

  am 27. Mai 2010 um 11:36 Uhr

  Bin ich noch nicht glücklich mit. Wenn ich Abhängigkeiten manuell setze, dann habe ich doch ebenfalls an zig Stellen im Code fest eingebaut was benutzt werden soll, z.B. welcher Logger. Wie wechsele ich denn diese nun aus ohne alle diese Code-Stellen zu ändern?

  Eine Registry hätte ja wenigstens den Vorteil, dass ich das jeweils verwendete Objekt an einer zentralen Stelle ändern kann.

• 
  

  Sven

  am 27. Mai 2010 um 11:45 Uhr

  @Thomas
  Objekte sollen auch nicht nur über den Konstruktur erzeugt werden (also kein $myObj = new MyClass()), sondern über den IOC-Container geholt/ erzeugt werden. Also $myObj = IocContainer::getClass(‘MyClass’). Der IOC-Container muss natürlich korrekt konfiguriert sein, damit alle Klassen auch sauber erzeugt werden.

  Wobei man in der Tat mit einer Übergabe der Werte im Konstruktor eine bessere Dokumentation im Code hat und auch im Fehlerfall schneller erkennen kann wo die Ursache liegt.

• 
  

  ragtek

  am 27. Mai 2010 um 12:08 Uhr

  @sven naja bei mir ist es etwas schwierig.

  Die Klasse holt Artikel aus dem Shop und gibt diese aus.

  Da ich nicht weiß, wie die DB beim Benutzer aufgebaut ist (es ist möglich das die Shoptabellen in der selben DB wie das vBulletin sind, aber es ist genauso möglich dass es sich um 2 verschiedene Datenbanken handelt, dann brauche ich eine 2. Verbindung) brauche ich das.
  Falls eine 2. Verbindung übergeben wird, benutze ich diese, ansonsten die “vB eigene” aus der Registry.

• 
  

  Ulf Kirsten

  am 27. Mai 2010 um 12:16 Uhr

  Ich will auch mal ein paar kritische Worte zum IoC / DI – Pattern loswerden. Im Prinzip wird das Pattern doch nur so massiv verwendet, weil es die Testbarkeit von Code so erhöht (was natürlich grundsätzlich gut ist). Ansonsten hat das Pattern ohne Anwendung eines DOC (Dependency Injection Container) auch durchaus Nachteile. Will ich meinen Logger bei DC austauschen, musst ich dies bei jeder Objekt-Instanzierung tun, wenn ich es hart verdrahtet im Constructor habe, habe ich nur eine Stelle zum Anpassen (DRY-Principle).

  @Christian
  Zend_Registry ist nichts anderes als ein globaler Container. Früher hat man dafür noch globale Variablen verwendet, heutzutage ist man mehr OO & cooler und nimmt eine registry. Bleibt aber das gleiche! (Was im übrigen gut ist, eine Registry erleichert das Programmieren enorm, da es global vorgehalten werden kann, bei einem exzessiven Gebrauch sollte man aber auch überlegen ob man software architektonisch alles richtig macht).

  @Sven
  Danke, schöner Beitrag! Würde gerne vor allem mehr noch dazu lesen, wo denn der Unterschied zwischen IoC und DI liegt, denn DI ist doch nur eine Art von IoC. Was sind denn andere Möglichkeiten?

• 
  

  Sven

  am 27. Mai 2010 um 12:17 Uhr

  @jonas
  Wie man IOC in der Praxis einsetzen kann darauf werde ich in meinem nächsten Artikel eingehen. Erst einmal wollte ich die Grundlagen zeigen also wozu das ganze eigentlich sinnvoll ist. Da wirst du sehen, dass man diese Dinge eben nur an einer Stelle zentral definiert und konfiguriert.

• 
  

  foaly

  am 27. Mai 2010 um 12:44 Uhr

  Wenn sich der Bezeichner ändert, muss doch immer noch Code an verschiedenen Stellen angepasst werden (beim Setter jeder Klasse). Nur sind es eben andere Stellen. Ich sehe den Vorteil in dieser Hinsicht nicht.

• 
  

  Stephan Hochdoerfer

  am 27. Mai 2010 um 13:06 Uhr

  Die Verbesserung der Testbarkeit ist das am häufigsten genannte Kriterium für den Einsatz von DI. Ich bin überzeugt davon dass es aber noch weitere Vorteile bringt, das zeigt mir zumindest meine Erfahrung aus den letzten 4 Jahren. Durch DI wird der Programmcode viel lesbarer und somit übersichtlicher da man sich quasi nur noch mit der Business-Logik befasst. Die Konfiguration wird nach extern ausgelagert, unabhängig davon ob dies in PHP, XML, YAML oder JSON erfolgt.

  Je nach Anwendungsfall lässt sich eine reale Klasse via Konfiguration in verschd. Ausprägungen verwenden ohne dass der Entwickler dabei mehr Programmcode schreibt. Auf der anderen Seite lässt sich beispielweise bei der Entwicklung die Schnittstelle zu einem externen Webservice gegen eine Dummy-Implementierung austauschen und somit die Responses beeinflussen. Programmcode wird dabei nicht verändert, nur die Konfiguration. Klingt banal, ist es auch

  Das ganze setzt aber voraus dass man ein Framework verwendet welches auf DI getrimmt wurde. Den Einsatz eines einfachen DI Containers würde ich nicht empfehlen man damit die Anwendung wieder abhängig von einer externen Komponente (dem DI Container) macht.

• 
  

  Stephan Hochdoerfer

  am 27. Mai 2010 um 13:13 Uhr

  @Ulf: Das Beispiel mit dem Logger ist nicht ganz korrekt. Du musst dich nicht darum kümmern die Abhängigkeiten an den Consumer weiterzugeben. Das wird vom DI Container erledigt. Du musst einzig beim Container nach der passenden Instanz fragen und bekommst diese dann fertig konfiguriert geliefert. Dies dürfte meiner Meinung nach auch der große Unterschied zwischen einer Registry und einem DI Container zu sein. Die Registry ist dumm und liefert nur das was du reinsteckst zurück. der DI Container hingegen instanziiert die Objekte und deren Abhängigkeiten eigenständig und weiß wann und wie er eine Instanz zurückgeben muss (aufgrund seiner Konfiguration).

• 
  

  Marc

  am 27. Mai 2010 um 14:46 Uhr

  Was haltet ihr denn in diesem Zusammenhang von Signalen und Slots ?

  Ich finde darüber könnte man auch mal reden.

• 
  

  Ulf Kirsten

  am 27. Mai 2010 um 18:30 Uhr

  @Stefan
  Klar, bei Verwendung eines DI-Containers hast du die Code-Stelle auch wieder gekapselt, ich bin aber bei meinem Beispiel davon ausgegangen das dieser nicht vorhanden ist. Das sehe ich selbst so öfters (und mache es auch selber so ), da es im PHP-Bereich einfach einen Mangel an guten DI-Containern gibt. Bei Spring ist das z.B. eine Wohltat, da kann man nicht viel falsch machen (bzw. wenn man etwas falsch macht, dann funktioniert es eh nicht).

• 
  

  Ulf Kirsten

  am 27. Mai 2010 um 18:31 Uhr

  Argh sorry, was für ein peinlicher Vertipper beim Namen, entschuldigung! Wieso kann man bei WP nicht seine Kommentare editieren?

• 
  

  Julian

  am 27. Mai 2010 um 19:01 Uhr

  Guter Artikel, auch wenn nur Grundzüge angerissen werden.

  Ich möchte allerdings noch einmal darauf hinweisen, dass Setter-Injection aus meiner Sicht kein guter Weg ist.

  In Java würde man sich früher oder später mit NullPointer-Exceptions konfrontiert sehen.

  Besser im Konstruktor und wissen, dass alles nötige initialisiert wurde!

• 
  

  Ulf

  am 27. Mai 2010 um 20:41 Uhr

  @Julian
  Das Argument ist bei PHP nicht so relevant, da man durch entsprechende TypeHins bei den Setter-Parameter ein Null-Value ausschließen kann. Im Gegensatz zu Java ist nämlich null kein WhatSoEverObject.

  Trotzdem würde ich gründsätzlich auch eher Construktur-Injection bevorzugen. Ein guter DI-Container kann diese Funktionalität aber sicherlich auch gut mit settern und der magischen __set Methode umsetzen. Zwar dann wieder schwierig zu debuggen und nachzuvollziehen, aber fancy…

• 
  

  Inversion of Control | Webentwicklung im Alltag

  am 27. Mai 2010 um 22:55 Uhr

  [...] ist mein Artikel Inversion of Control auf PHP hates me erschienen. Danke nochmal an Nils, dass er mir diese Plattform geboten hat um meine Artikel auch [...]

• 
  

  nikosch

  am 29. Mai 2010 um 23:48 Uhr

  > da man durch entsprechende TypeHins bei den Setter-Parameter ein Null-Value ausschließen kann.

  nicht, wenn man die Setter vergisst aufzurufen

• 
  

  ragtek

  am 30. Mai 2010 um 11:37 Uhr

  Wann ist den mit dem 2. Teil zu rechnen?

• 
  

  Sven

  am 30. Mai 2010 um 11:52 Uhr

  Ich versuche ihn diese Woche zu schreiben. Darin möchte ich einerseits zeigen wie man selber einen simplen IoC Container programmiert (einfach um die Hintergründe zu verstehen) und dann auch noch einen kurzen Überblick über bestehende IoC-Container auf dem Markt.
  Sollte dann also in den nächsten 1-2 Wochen hier erscheinen.

• 
  

  Jonathan Schmid

  am 30. Mai 2010 um 14:30 Uhr

  Jonathan Schmid gefällt das.

• 
  

  ragtek

  am 15. Juni 2010 um 16:40 Uhr

  Ich frag mal vorsichtig nach, ohne nerven zu wollen;)
  Teil 2???*g*

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar