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.

dotnetpro

Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde
  • 2 Monate Gratis testen
  • Über 4.000 qualifizierte Fachartikel
  • Auf jedem Gerät verfügbar