Dependency-Injection ist nicht Inversion-of-Control

Eine der Regel für gutes Software-Design besagt, dass es wichtig ist, eine feste Kopplung zwischen einzelnen Klassen Ihrer Anwendung zu vermeiden. Um dies erreichen zu können, muss man die Abhängigkeiten einer Klasse von außen in die Klasse injizieren. Hier sprechen wir also von der „Dependency-Injection“. Eine Injizierung kann ebenso über den Constructor oder über eine Setter-Methode erfolgen. Hier ein Quellcode-Beispiel.

Vorher: feste Kopplung

class Storage
{
    public function store()
    {
        // store it to a XML file.
    }

    // ....
}

class User
{
    protected $_name;

    public function save()
    {
        $storage = new Storage();
        $storage->store();

        // ....
    }
}

Nachher: lose Kopplung

interface Storage
{
    public function store();
}

class XmlStorage implements Storage
{
    public function store()
    {
        // store data to XML file.
    }

    // ....
}

class MySqlStorage implements Storage
{
    public function store()
    {
        // store data to MySQL.
    }

    // ....
}

class User
{
    protected $_name;

    public function save(Storage $storage)
    {
        $storage->store();

        // ....
    }
}

Wir haben somit eine sehr lose Kopplung zwischen den einzelnen Komponenten erreicht. Die Klasse User weiß nicht welche Implementierung sie des Storage-Interface verwendet. Sie verlässt sich vollkommen darauf, dass die gewünschte Implementierung an die Klasse übergeben wird. Man nennt es auch die Umkehrung der Abhängigkeiten oder auch das Inversion-of-Control Prinzip. Die Klasse User selbst steuert nicht mehr, wie sie an ihre Abhängigkeiten kommt, der Kontrollfluss wird von außerhalb der Klasse gesteuert.

Trotzdem darf man das Inversion-of-Cointrol Prinzip mit der Dependency-Injection nicht gleich setzen. Inversion-of-Controll ist ein Prinzip was definiert, dass der Kontrollfluss nicht bei der Hauptanwendung liegt, sondern dieser an ein Framework abgegeben wird. Das Framework kümmert sich dann, dass innerhalb des Kontrollflusses die von der Anwendung bereitgestellten Funktionen und Anhängigkeiten aufgerufen werden. Die Klasse wartet darauf, dass sie von der Applikation an- bzw. aufgerufen wird und die Abhängigkeiten übergeben bekommt.

4 thoughts on “Dependency-Injection ist nicht Inversion-of-Control

  1. Nunja, das ist fachlich nur bedingt korrekt. IoC ist ein Paradigma aus dem Software Design bzw. aus der Software Architektur -> Nicht das Objekt organisiert die Abhängigkeiten sondern eine andere Ebene der Applikation. Welche dies ist, wird durch IoC nicht definiert. Dependency Injection ist wiederum ein Design Pattern und eine „konkrete Implementierung“ des IoC Paradigmas. DI fängt zwar mit dem Design by Contract, welches Du beschrieben hast, an, jedoch hört es damit nicht auf. Vgl. http://www.slideshare.net/mariomueller/dependency-injection-8133766

  2. Hey Gjero,

    ich mach aktuell aktiv kein PHP mehr, daher kann ich Dir dazu keine fundierte Meinung geben. Ich schau mir grade das Service Konzept von Symfony2 an, was mich stark an Spring aus der Java Welt erinnert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.