Quelle: dotnetpro
Composite Components 2.0, Teil 11 14.09.2020, 00:00 Uhr

Unabhängigkeit ist Trumpf

Nur entkoppelte Abhängigkeiten können qualitative Softwareentwicklung ermöglichen.
Die vorangegangene Episode von Davids Deep Dive hat sich mit einem der wichtigsten Leitsätze in der Softwareentwicklung beschäftigt: Niemals gegen Implementierung arbeiten, sondern nur gegen Kontrakte. Der entscheidende Punkt dabei: Eine Abhängigkeit gegen eine Implementierung bedeutet, dass sich qualitative Aspekte wie Wiederverwendbarkeit, Austauschbarkeit und Testbarkeit nicht erfüllen lassen. Besteht dagegen eine Abhängigkeit von einem Kontrakt, so ist die dahinterliegende Implementierung unerheblich; sie ist flexibel, denn sie lässt sich einfach austauschen, ohne dass der Aufrufer dies mitbekommt. Falls Sie zu diesem Punkt noch etwas Nachholbedarf haben, empfehle ich, die vorige Episode zu studieren [1] oder auf meinem YouTube-Kanal das entsprechende Video anzusehen [2].
Die vorliegende Episode soll nun zeigen, wie eine Abhängigkeit von Implementierungen in eine Abhängigkeit von Kontrakten umgewandelt werden kann. Dieser Vorgang wird Entkopplung genannt und er wird zunächst mit Klassen und anhand eines Beispiels abstrakt mit einem Systemmodell gelöst. „Warum denn abstrakt?“, werden Sie sich nun womöglich fragen, haben Sie doch als Entwickler bestimmt schon tausendfach Abhängigkeiten auf Klassenebene mit Schnittstellen entkoppelt. Das ist auch zweifelsohne das richtige Vorgehen. Allerdings ist das nicht die Denkweise, die Sie als Architekt benötigen. Wie die Episode zum Thema „Modularisierung“ gezeigt hat, lässt sich jedes Programmierkon­strukt (Statement, Methode, Klasse, Komponente, Schicht, Dienst und auch die Anwendung selbst), dessen Quellcode strukturiert werden soll, als System auffassen [3].

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