Quelle: dotnetpro
Composite Components 2.0, Teil 10 17.08.2020, 00:00 Uhr

Abhängigkeiten genau betrachtet

In einer Anwendung machen Abhängigkeiten qualitative Aspekte zunichte. Kontrakte lösen das Problem.
Die letzten beiden Episoden von Davids Deep Dive haben gezeigt, was Komponenten genau sind und wie diese Komponenten am besten geschnitten werden sollten [1][2]. Sollten Sie diese Artikel noch nicht gelesen haben, so empfehle ich dringend, dies nachzuholen. Sie können aber auch auf meinem YouTube-Kanal die begleitenden Videos anschauen [3].
Die vorliegende neue Episode nun widmet sich einem Umstand, der es schwierig macht, sowohl Komponenten als auch Klassen in einer Architektur gut und effizient einsetzen zu können. Das grundlegende Problem: Nach dem derzeitigen Stand der Composite Components 2.0 sind es die Abhängigkeiten zwischen Klassen und Komponenten, die den Aspekten wie Wiederverwendbarkeit, Austauschbarkeit und Lesbarkeit massiv zuwiderlaufen. Für eine flexible, testbare und erweiterbare Architektur sind diese Aspekte aber von größter Bedeutung, und so steht auf dem Weg zur Composite-Component-2.0-Architektur nur noch diese Hürde im Weg. Daher wird sich diese Episode mit dem Problem der Abhängigkeit beschäftigen und genauer beleuchten, warum diese immer nur gegen Kontrakte und niemals gegen Implementierungen gehen sollten.

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