Quelle: dotnetpro
Liesers Clean Code 17.10.2022, 00:00 Uhr

Dependency Inversion Principle und Lifecycle-Aspekte

Die guten Seiten des DIP – und wieso IoC-Container eine Clean-Code-Developer-Praktik sind.
S chon häufiger habe ich in der Vergangenheit darüber ­geschrieben (unter anderem in [1]), dass ich das Dependency Inversion Principle (DIP) für überbewertet halte. Das liegt am Integration Operation Segregation Principle (IOSP). Kurz gesagt ist es nicht mehr notwendig, die Abhängigkeitsrichtung umzudrehen, wenn den Abhängigkeiten ein eigener Platz zugewiesen wird. Mache ich Integrationsmethoden ausschließlich für den Aspekt der Integration von Abhängigkeiten verantwortlich, ist in der Folge die Inversion nicht mehr notwendig. So weit, so gut.
Es stellt sich jedoch immer wieder die Frage, ob denn Dependency Injection (DI) damit ebenfalls überbewertet sei. Aus dem DIP folgt, dass wir Klassen, von denen andere Klassen abhängig sind, mit einem Interface versehen. Dadurch wird die Abhängigkeitsrichtung über das Interface in ihrer Richtung gedreht. Als Nächstes ergibt sich daraus dann in der Regel die Praktik der Dependency Injection: Die Abhängigkeiten werden nicht mehr an der Verwendungsstelle instanziert, sondern als Parameter an den Konstruktor übergeben. Wenn man das konsequent macht, kann ein IoC-Container (Inversion of Control) verwendet werden, um die Konstruktorparameter auszufüllen. Der Umgang mit Interfaces und der Einsatz eines IoC-Containers sollen im Folgenden beleuchtet werden.

Jetzt 1 Monat kostenlos testen!

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
  • + Digitales Kundenkonto,
  • + Zugriff auf das digitale Heft,
  • + Zugang zum digitalen Heftarchiv,
  • + Auf Wunsch: Weekly Newsletter,
  • + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar