Abhängigkeitsinjektion: Warum nicht einfach den Container injizieren?

Anpackung aufgeblähter Konstrukteure in der Abhängigkeitsinjektion

überaus komplexe Konstruktorsignaturen wie dieses Beispiel:

<code>public MyClass(Container con, SomeClass1 obj1, SomeClass2 obj2, ... )</code>

sind ein häufiges Problem. Warum nicht einfach den Container (Container con) direkt in jede Klasse injizieren? Dies vereinfacht die Konstruktoren erheblich, aber es ist mit erheblichen Nachteilen verbunden. Es verwandelt den Behälter im Wesentlichen in eine verherrlichte statische Fabrik.

Das Problem mit verherrlichten Statik und Kontrollinversion (IOC)

Verwenden des Containers als Service Locator lässt es sich wie ein globaler statischer Zugangspunkt verhalten. Dies verstößt gegen das Prinzip der einzelnen Verantwortung und erschwert das Testen und die Wartbarkeit. Die Klasse wird eng mit der Implementierung des Behälters gekoppelt, die Flexibilität und Wiederverwendbarkeit behindert.

Refactoring mit Fassadendiensten

Die Stärke der Konstruktorinjektion liegt in ihrer Fähigkeit, Verstöße gegen das Prinzip der einzelnen Verantwortung hervorzuheben. Wenn Konstruktoren unhandlich werden, ist es ein klares Signal für das Refactoring. Die Lösung besteht häufig darin, Fassadendienste zu erstellen.

Fassadendienste führen eine höhere, abstraktere Schnittstelle ein. Diese Grenzfläche verbirgt die Komplexität der Interaktion mit zahlreichen feinkörnigen Abhängigkeiten. Dies fördert sauberer, überschaubarer Code und verbessert die Testbarkeit.

Das obige ist der detaillierte Inhalt vonAbhängigkeitsinjektion: Warum nicht einfach den Container injizieren?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!