Hallo Zusammen,

ich habe mich in letzter Zeit intensiver damit beschäftigt, wie man Anwendungen leichter wartbar machen kann. Insbesondere war für mich wichtig, dass Komponenten austauschbar sind, um kurzfristiger auf Änderungswünsche reagieren zu können.

Daher habe ich in meiner letzten Anwendung erstmalig, fast alles via Interfaces implementiert. Die jeweiligen Konstruktoren verlangen also Interfaces. Im „Entry Point“ des Programms habe ich dann mittels DI-Container sämtliche Interfaces referenziert.

Funktioniert auch alles super. Austausch- und Wartbarkeit sind voll gegeben. Allerdings ist der „Zusammenbau“ des DI-Containers schon recht kompliziert, da man ja sämtliche Interfaces bis in die unterste Hierarchiestufe referenzieren muss.

Bsp:
KlasseA:
Ctor KlasseA(IKlasseB, IKlasseC)

KlasseB:IKlasseB
Ctor KlasseB(IKlasseD, IKlasseE)

…

Ich kann mir auch nicht vorstellen, dass das so der Weg in richtig großen Projekten ist, auch wenn hier Austauschbarkeit und Wartbarkeit eine noch größere Rolle spielen.

Kann mir hier jemand sagen, wie man bzgl. Softwarearchitektur hier vernünftig vorgehen kann?

Gruß

Frank

Hallo,

vom Prinzip her ist es schon richtig, daß bei IoC (DI) alle Abhängigkeiten als Parameter übergeben werden.
Je nach verwendeten DI-Framework gibt es aber verschiedene Möglichkeiten:
- Injection per Konstruktor
- Injection per Methode (falls eine abhängige Klasse nur in wenigen Methoden benutzt wird)
- beim DI-Framework die registrierte abhängige Klasse anfordern

Hierbei sollte man natürlich auch beim Design der Klassen darüber nachdenken, die Abhängigkeiten zu reduzieren (denn je größer die sog. "zyklomatische Komplexität" (cyclomatic complexity), desto schwieriger ist es diese Klasse zu warten bzw. zu testen).

Den goldenen Weg gibt es wohl selten, d.h. mit möglichst wenig Aufwand maximale Unabhängigkeit zu erreichen...

Auch bei meinem aktuellen Projekt stehe ich immer wieder vor ähnlichen Problemen, wie ich die Abhängigkeiten auflöse bzw. reduziere, ohne den Code mit x Schnittstellen und Klassen erweitern zu müssen. Insbesondere für die Unit-Tests (wir setzen dafür zusätzlich ein Mocking-Framework ein), merke ich aber, daß dies wohl zwingend notwendig ist (aber wir sind jetzt gerade erst in der FUM (Funktionsmuster) Phase, so daß also noch einige Änderungen auf uns zukommen werden).