nicht angemeldet
Rolf BHallo pl,
DI, so wie dedlfix sie beschreibt, führt zu stärker entkoppeltem Code. Das ist abstrakter und bewirkt, dass man dem Sourcecode erstmal nicht mehr ansieht, welche konkrete Klasse da eigentlich mit welcher interagiert.
Insofern hast Du recht.
Andererseits bist Du auf diese Abstraktion angewiesen, wenn Du testbaren Code schreiben willst (sei es im Sinne von test driven development, oder sei es lediglich im Sinne von a posteriori geschriebenen Unittests).
Klassen, die sich ihre Abhängigkeiten selbst beschaffen, sind nicht isoliert testbar. Isolierte Tests sind aber wichtig, um automatisiert Codeteile testen zu können und damit eine fortlaufende Integration von Softwareänderungen zu ermöglichen.
Wenn sich Klassen ihre Abhängigkeiten über Aufrufe einer Factory beschaffen, brauchst Du eine konfigurierbare Factory, um bei Unittests die Mocks/Stubs unterschieben zu können. D.h. du verschiebst die Injektion aus den Konstruktorparametern in die Factory. Aber eigentlich hast Du nur einen DI-Container gebaut.
Ob man die Injektion aus dem DI Container in die Klasse nun über Konstruktorparameter löst, oder ob sich der Konstruktor die Abhängigkeiten aus dem DI Container abholt, macht oft keinen Unterschied. Es schafft aber eine unnötige Abhängigkeit (nämlich von der Klasse, deren Objekt erzeugt wird, zum DI-Container) und ZWINGT Dich, den DI Container zu verwenden. In Unit Tests ist es aber viel einfacher, ohne den Container zu arbeiten und die Mocks direkt einzuspritzen.
Übrigens kann man auch Factory-Klassen einspritzen und auf diese Weise erreichen, dass nicht alle abhängigen Objekte a priori existieren müssen. Das echte Objekt wird erzeugt (und ggf. sogar dynamisch geladen), sobald die erste Methode aufgerufen wird. Geht alles. Und die Klasse, der da was eingespritzt wird, weiß überhaupt nicht, was passiert. UND DARAUF KOMMT'S AN. Maximale Entkoppelung.
Rolf
Dosen sind silbern