Separation of Concerns

Ein größeres Computerprogramm besteht aus vielen Teilen, die zusammenarbeiten. Separation of Concerns heißt übersetzt « Trennung der Zuständigkeiten ». Das Prinzip verlangt, dass jeder Teil des Programms für genau eine klar abgegrenzte Aufgabe verantwortlich ist. Ein Teil holt Daten aus dem Speicher, ein anderer rechnet damit, ein dritter zeigt das Ergebnis auf dem Bildschirm. Diese Teile wissen möglichst wenig voneinander und tauschen nur das Nötigste aus. Der Begriff geht auf den niederländischen Informatiker Edsger Dijkstra zurück, der ihn 1974 beschrieb.

Warum vermischter Code irgendwann unbezahlbar wird

Software wird selten einmal geschrieben und dann nie wieder angefasst. Sie wird jahrelang erweitert, korrigiert und angepasst. Wenn alles mit allem vermischt ist, hat jede kleine Änderung unvorhersehbare Folgen an ganz anderen Stellen. Entwickler nennen so etwas « Spaghetticode »: Man zieht an einer Nudel und der halbe Teller bewegt sich mit.

Getrennte Zuständigkeiten begrenzen den Schaden. Wenn nur ein Baustein für die Anzeige zuständig ist, kann man das Design ändern, ohne die Rechenlogik anzufassen. Auch Fehlersuche wird einfacher. Zeigt die App einen falschen Preis an, muss man nur wenige klar benannte Stellen prüfen.

Dazu kommt die Arbeitsteilung. In einem Team von zwanzig Leuten können mehrere Personen gleichzeitig arbeiten, ohne sich ständig in die Quere zu kommen. Jeder ist für andere Bausteine zuständig. Ohne saubere Trennung blockieren sich Teams gegenseitig, und die Entwicklung wird mit wachsender Größe immer langsamer.

Schnittstellen als Grenzen zwischen den Bausteinen

In der Praxis zieht man Grenzen mit sogenannten Schnittstellen. Eine Schnittstelle ist eine Vereinbarung darüber, welche Anfragen ein Baustein beantwortet und welche Antwort er liefert. Wie er das intern macht, bleibt sein Geheimnis. Man kann den Baustein später komplett neu schreiben, solange die Vereinbarung gleich bleibt.

Ein verbreitetes Muster ist die Aufteilung in Schichten. Die Datenschicht spricht mit der Datenbank, die Logikschicht enthält die eigentlichen Regeln, die Oberflächenschicht kümmert sich um das, was der Nutzer sieht. Jede Schicht spricht nur mit der direkt darunterliegenden. Eine ähnliche Idee steckt hinter Microservices, also vielen kleinen Programmen, die je einen Teilbereich abdecken.

Ein häufiger Irrtum ist, dass mehr Trennung immer besser sei. Jede Grenze kostet etwas: mehr Dateien, mehr Vereinbarungen, bei Microservices auch Netzwerkverkehr zwischen den Teilen. Wer ein winziges Programm in fünfzig Bausteine zerlegt, macht es unübersichtlicher statt klarer. Sinnvoll ist die Trennung dort, wo sich Aufgaben wirklich unabhängig voneinander verändern.

Von Schulprojekten bis zu KI-Systemen

Wer selbst programmiert, begegnet dem Prinzip früh. Schon eine kleine Webseite trennt Inhalt, Gestaltung und Verhalten in verschiedene Dateien: HTML für den Text, CSS für das Aussehen, JavaScript für die Interaktion. Genau das ist Separation of Concerns im Kleinen. Man kann das Aussehen komplett austauschen, ohne den Inhalt anzufassen.

In KI-Produkten ist die Trennung besonders sichtbar. Ein Chatbot besteht meist aus einem Sprachmodell, das Text erzeugt, einer Suchkomponente, die Fakten aus Dokumenten holt, und einer Filterschicht, die problematische Antworten blockiert. Diese Teile werden getrennt entwickelt und getrennt ausgetauscht. Ein Anbieter kann das Sprachmodell durch ein neueres ersetzen, ohne die Suche neu zu bauen.

Auch in Wirtschaftsnachrichten taucht das Thema indirekt auf. Wenn ein Unternehmen berichtet, es habe seine alte Software modernisiert oder in Microservices zerlegt, geht es fast immer um dieses Prinzip. Solche Umbauten dauern oft Jahre und kosten viel Geld. Der erhoffte Gewinn ist, dass neue Funktionen danach in Wochen statt in Monaten entstehen.