Struktur, Kopplung und SOLID als Heuristik

Struktur, Kopplung und SOLID als Heuristik

0:00 Das dritte Modul geht eine Ebene höher: von einzelnen Regeln zur Struktur. Wo ziehe ich Grenzen zwischen Modulen, in welche Richtung dürfen Abhängigkeiten zeigen, und was ist eigentlich von SOLID zu halten? Beim letzten Punkt werden Sie merken, dass ich mich um eine Lagerposition drücke — und das ist Absicht. Die Frage ist nicht, ob SOLID gut oder überholt ist.

0:21 Die Frage ist, wann man diese fünf Buchstaben anwendet. Der Unterschied liegt im Zeitpunkt, und er entscheidet über Nutzen oder Schaden.

Struktur, Kopplung und SOLID als Heuristik

0:30 Wir schließen den ersten Tagesblock zu den Grundlagen mit der Strukturfrage ab. Was hier besonders ist: Das wichtigste Kriterium dieses Moduls stammt aus dem Jahr 1972 und beschreibt einen Fehler, den wir bis heute machen — nur mit moderneren Werkzeugen. Ein Kriterium, das ein halbes Jahrhundert überdauert hat, lässt sich schlecht mit dem Verweis auf ein aktuelles Framework abtun. Deshalb steht es hier im Zentrum.

Separation of Concerns und Modulgrenzen

0:55 Beginnen wir mit der Frage, an der Architekturen am häufigsten scheitern: Wo schneidet man? Die verbreitete Antwort — Controller, Service, Repository — sieht ordentlich aus und ist trotzdem meist die falsche. Warum das so ist, hat jemand schon 1972 aufgeschrieben, lange bevor es diese Schichtnamen überhaupt gab. Sein Kriterium ist unbequem, weil es mehr Nachdenken verlangt als eine Schichtung.

1:20 Ein Belang ist ein Thema, um das sich jemand kümmern muss: die fachliche Regel, die Speicherung, die Darstellung, die Berechtigung, die Benachrichtigung. Trennung der Belange heißt, dass diese Themen im Code getrennt liegen und über bewusst gewählte Übergänge miteinander sprechen. Der Nutzen zeigt sich immer erst beim Ändern und beim Testen — vorher sieht auch der schlechte Schnitt ordentlich aus.

1:41 Der Begriff selbst geht übrigens auf Dijkstra zurück und ist damit ähnlich alt wie das Kriterium, das gleich kommt. Hier stehen zwei Kriterien nebeneinander, und der Unterschied ist folgenreich. Oben: Man schneidet am Ablauf des Programms — heraus kommen Controller, Services und Repositories. Das Problem steht rechts: Jede fachliche Änderung fasst alle drei an.

2:04 Unten: Man schneidet danach, was sich voraussichtlich ändern wird — heraus kommen Fahrzeuge, Buchung, Abrechnung. Die Änderung bleibt dann in einer Ecke. David Parnas hat 1972 geschrieben, es sei fast immer falsch, die Zerlegung an einem Flussdiagramm zu beginnen. Und genau das ist die technische Schichtung: die moderne Form des Flussdiagramm-Schnitts.

2:27 Es gibt einen zuverlässigen Test, und er kostet nichts. Schauen Sie sich an, was ein Test hochfahren muss. Liegt die Regel zur Doppelbuchung in derselben Funktion wie der Datenbankzugriff, dann braucht jeder Test dieser Regel eine Datenbank. Und das ist nicht nur lästig — die Regel lässt sich dann auch nicht mehr allein durchdenken, weil man sie nicht mehr allein sieht.

2:48 Das ist der praktische Kern: Fachliche Änderungen fallen fast immer in eine Ecke, technische fast nie. Ein Schnitt, der der Fachlichkeit folgt, trägt deshalb länger.

Kopplung und Kohäsion beurteilen

2:58 Zwei Begriffe, die jeder kennt und die trotzdem selten operationalisiert werden. Wenig Kopplung, hohe Kohäsion — das sagt sich leicht. Die Frage ist, woran Sie das im Alltag festmachen wollen, ohne ein Werkzeug anzuwerfen. Wir sehen uns zwei Fragen an, die dafür genügen, und ich sage gleich dazu, was sie sind und was nicht.

3:18 Kopplung beschreibt, wie stark ein Baustein von anderen abhängt. Kohäsion, wie gut zusammengehört, was in ihm steckt. Beide Begriffe stammen aus der strukturierten Programmierung der siebziger Jahre — Stevens, Myers und Constantine, 1974. Und hier kommt der Punkt, der selten gesagt wird: Sie sind seither nie verbindlich in Zahlen gefasst worden. Es gibt keine anerkannte Metrik dafür.

3:43 Wer eine sucht, sucht seit fünfzig Jahren vergeblich. Für den Alltag genügen deshalb zwei Fragen, die sich in Sekunden stellen lassen. Die erste Frage: Wenn ich diesen Baustein ändere, wie viele andere muss ich anfassen oder wenigstens erneut prüfen? Das ist die Kopplung. Und am ehrlichsten lesen Sie sie nicht an den Importen ab, sondern daran, was ein Test alles hochfahren muss — Importe kann man verstecken, eine Testeinrichtung nicht.

4:09 Die zweite Frage: Wenn ich beschreiben soll, wofür der Baustein zuständig ist, brauche ich dafür ein Und? Jedes Und ist ein Hinweis auf mangelnde Kohäsion. Beide Fragen können Sie auch einem Agenten stellen — nur ist die Antwort dann eine Hypothese, die Sie am Code nachprüfen. Der erste Punkt ist der wichtigste im Umgang mit Werkzeugen: Die Antwort des Agenten ist eine Hypothese, keine Messung. Sie klingt nur wie eine.

4:35 Der zweite betrifft die bequeme Abkürzung — Kopplung an der Zahl der Importe ablesen. Das unterschätzt regelmäßig, weil die eigentliche Kopplung oft über gemeinsamen Zustand läuft. Der dritte ist ein verbreiteter Denkfehler: Hohe Kohäsion ist nicht dasselbe wie kleine Dateien. Und der vierte ist eher ein Rat: Suchen Sie nicht nach der Metrik.

4:56 Es gibt sie seit 1974 nicht.

Abhängigkeitsrichtung und Stabilität

4:59 Jetzt zu einem Punkt, der oft unter einem Fachbegriff versteckt wird und im Kern ganz einfach ist. Es geht nicht darum, wie viele Abhängigkeiten es gibt, sondern wohin sie zeigen. Diese eine Unterscheidung erklärt einen erheblichen Teil dessen, was unter Architektur verhandelt wird — und sie lässt sich in jeder Sprache und mit jedem Framework anwenden.

5:19 Die Faustregel lautet: Das Beständige soll nichts vom Wechselhaften wissen. Und gleich eine Warnung zum Begriff: Stabil heißt hier änderungsarm, nicht zuverlässig. Diese Verwechslung passiert ständig und führt in die Irre. Im Fahrtenbuch sind die fachlichen Regeln das Beständige — wann eine Buchung gültig ist, wie ein Zweck die Abrechnung bestimmt. Das ändert sich selten und ist wertvoll.

5:42 Die Anbindung an eine bestimmte Datenbank, ein Exportformat, einen Mailversand ändert sich häufig. Beides ist nötig, aber nicht gleich schützenswert. Zwei Zeilen, und der Unterschied entscheidet über die Wartbarkeit. Oben: Die Buchungsregel kennt das CSV-Format. Damit reißt jede technische Umstellung an der Fachlichkeit — Sie ändern ein Exportformat und fassen dabei Code an, in dem Steuerlogik steht.

6:07 Unten: Der CSV-Export kennt die Buchungsregel. Jetzt bleibt die Fachlichkeit unberührt, egal wie oft das Format wechselt. Das ist der ganze belastbare Kern hinter dem Begriff Abhängigkeitsumkehr, und er ist es wert, verstanden statt nachgesprochen zu werden. Beachten Sie: Dafür braucht es oft gar kein zusätzliches Interface.

6:28 Die ersten beiden Punkte haben wir eben schon berührt und sie sind die häufigsten: Stabil als zuverlässig lesen, und Abhängigkeitsumkehr mit dem Einziehen von Interfaces gleichsetzen. Der dritte ist die übereifrige Variante — die Richtung umdrehen, obwohl es gar keine wechselhafte Seite gibt. Dann haben Sie Aufwand ohne Nutzen.

6:47 Und der vierte ist der unangenehmste, weil er eine ehrliche Selbsteinschätzung verlangt: Manches, was wir für stabile Fachlichkeit halten, wackelt in Wahrheit jedes Quartal.

SOLID als Heuristik, nicht als Gesetz

6:57 Und jetzt zu den fünf Buchstaben. Hier kommt der Widerspruch im Raum verlässlich aus beiden Richtungen — die einen halten SOLID für überholt, die anderen für Grundlage. Ich werde mich für keine der beiden Seiten entscheiden, und das ist kein Ausweichen. Beide Lager beschreiben etwas Richtiges, nur reden sie über verschiedene Zeitpunkte.

7:17 Die These lautet: Die fünf Buchstaben sind nützliche Diagnosehilfen und schlechte Bauvorschriften. Sie beantworten die Frage, wie man auf ein beobachtetes Problem reagiert — nicht die Frage, wie man vorsorglich baut, bevor man weiß, ob das Problem je auftritt. Darin liegt der ganze Unterschied zwischen nützlich und schädlich. Und deshalb heißt dieses Kapitel auch als Heuristik: Eine Heuristik stellt Fragen an etwas Vorhandenes.

7:42 Ein Gesetz schreibt vor, bevor irgendetwas da ist. Diese Tabelle ist das Herzstück des Kapitels, und ich empfehle, sie zeilenweise zu lesen. Links steht jeweils die Diagnosefrage, rechts der Schaden, den dieselbe Regel als Bauvorschrift anrichtet. Bei S: Hat der Baustein mehr als einen Änderungsanlass — eine gute Frage. Als Vorschrift gelesen: eine Klasse je Methode. Bei I: Zwingt die Schnittstelle zu Unnötigem — gute Frage. Als Vorschrift: eine Schnittstelle je Klasse.

8:13 Dan North hat die Kritik an der Gattung formuliert: Prinzipien wirken wie Regeln, man erfüllt sie oder nicht. Er schlägt stattdessen Eigenschaften vor — Richtungen statt Häkchen. Der erste Punkt ist die Kernfehlanwendung: die fünf als Checkliste vor dem Schreiben abarbeiten. Die beiden mittleren sind die Lagerpositionen, und sie sind beide unbrauchbar — pauschal für überholt erklären genauso wie pauschal verteidigen.

8:39 Wenn im Raum eine davon kommt, ist die Antwort nicht Widerspruch, sondern die Zeitpunkt-Unterscheidung von der vorigen Folie. Der letzte Punkt ist die praktische Folge für den Alltag: Ein Review, das Regelverstöße zählt, statt Probleme zu benennen, hat den Zweck verfehlt.

Warum mehr Abstraktion nicht sauberer heißt

8:55 Zum letzten fachlichen Kapitel dieses Moduls — und es hängt unmittelbar mit dem vorigen zusammen. Denn der Schaden der Bauvorschrift-Lesart besteht fast immer in zusätzlichen Abstraktionen: einer Schnittstelle hier, einer Fabrik dort, einer Ebene, die niemand angefordert hat. Sehen wir uns deshalb an, was eine Abstraktion eigentlich kostet und wann sich der Handel lohnt.

9:15 Die Antwort darauf ist erfreulich konkret und lässt sich in eine einzige Prüffrage fassen. Denken Sie an einen Adapter für Steckdosen. Er ist großartig, wenn Sie tatsächlich zwischen Ländern reisen. Wenn Sie nie das Land wechseln, haben Sie einfach ein Teil mehr zwischen Gerät und Steckdose — ein zusätzliches Ding, das kaputtgehen kann. Genauso ist es mit Abstraktionen.

9:38 Jede kauft Flexibilität an einer bestimmten Achse und bezahlt mit einer Ebene, die jeder Leser durchschreiten muss. Der Handel lohnt sich, wenn die Achse tatsächlich variiert. Tut sie es nicht, bleibt nur der Preis. Besonders teuer ist die falsch gewählte Achse: flexibel genau dort, wo nie etwas variiert, und im Weg dort, wo die Änderung kommt.

9:59 Das Vorgehen ist dasselbe wie bei den Erweiterungspunkten in Modul zwei, nur eine Ebene höher. Jede vorgeschlagene Indirektion einzeln benennen. Dann fragen: Welche Achse wird hier flexibel gemacht? Und dann die entscheidende Frage: Welche zwei konkreten, heute existierenden Fälle stehen dahinter? Zwei, nicht einer. Fällt die Antwort nur einer aus, ist es keine Abstraktion, sondern Verpackung.

10:23 Im Zweifel lassen Sie die Duplikation stehen und schneiden später richtig — das ist billiger, als es klingt. Der erste Punkt ist der Grund, warum falsche Abstraktionen so lange überleben: Die Aufrufer haben sich schon an sie gewöhnt. Der zweite ist die Dynamik, die Sandi Metz beschreibt — man bläht die falsche Abstraktion mit Parametern und Bedingungen weiter auf, weil die nächste Anforderung fast passt.

10:47 Der dritte ist ein Missverständnis, das ich klarstellen möchte: Das alles ist keine Erlaubnis für Copy-Paste. Die richtige Abstraktion bleibt besser als beides. Und der vierte ist der tröstliche: Der Rückweg aus einer nicht gebauten Abstraktion ist gratis.

Übung: Einen Abstraktionsvorschlag der KI bewerten

11:03 Zum Abschluss eine Übung, in der Sie genau das anwenden — und zwar an einem Vorschlag, den Sie sich selbst erzeugen lassen. Der Auftrag ist dabei bewusst vage gehalten, und Sie werden am Ergebnis sehen, warum das ein Problem ist. Der lehrreichste Teil kommt ganz zum Schluss, wenn Sie benennen sollen, was im Auftrag gefehlt hat. Das ist die Brücke zum nächsten Modul.

11:24 Sie bitten einen Assistenten, den Abrechnungsteil des Fahrtenbuchs sauberer zu strukturieren — ohne weitere Vorgaben. Nehmen Sie den Vorschlag dann ernst und zerlegen Sie ihn: Welche Ebenen kommen hinzu, welche Achse wird jeweils flexibel, und welcher heute existierende Fall rechtfertigt sie? Streichen Sie anschließend jede Ebene, für die Sie keine zwei realen Fälle benennen können.

11:46 Beurteilen Sie zum Schluss, ob der verbliebene Rest die Fachlichkeit besser sichtbar macht als der Ausgangszustand. Meistens tut er das — und das ist die eigentliche Erkenntnis. Fünf Schritte in einer Stunde. Vorschlag erzeugen, in Ebenen zerlegen, je Ebene Achse und rechtfertigenden Fall benennen, streichen, lesen. Der wichtigste Schritt ist aber der letzte, und den möchte ich hervorheben: Halten Sie in einem Satz fest, welche Vorgabe im Auftrag gefehlt hat.

12:13 Denn das ist die übertragbare Lehre — nicht, dass der Assistent zu viel gebaut hat, sondern dass ein Auftrag ohne Erfolgskriterium jedes Ergebnis erlaubt. Damit sind wir genau bei dem Thema, das Modul vier eröffnet.