Wenn ein Softwareprodukt über einen längeren Zeitraum weiterentwickelt werden soll, sind die mit zunehmender Komplexität steigenden Kosten oft einer der wichtigsten Constraints. Beim Beherrschen von Komplexität helfen verschiedene Software-Design-Praktiken und Prinzipien, die die Kosten für neue Funktionalität einigermaßen konstant halten sollen.
Leider ranken sich auch Missverständnisse und Mythen um manche dieser Design-Prinzipien, verbreiten sich oft schneller als die beabsichtigte Interpretation und können dadurch das Komplexitäts- und Kostenproblem sogar noch verschlimmern. Durch einen genaueren Blick auf die ursprünglichen Quellen lassen sich diese Mythen leicht entlarven.
Ich stelle Euch im Folgenden drei dieser Prinzipien und deren häufigste Mythen vor.
DRY - Don't Repeat Yourself
Diese Richtlinie besagt, dass jede Information bzw. jedes "Wissen" eine einzige, eindeutige Repräsentation haben soll. Insbesondere im Code, aber auch zum Beispiel in der Dokumentation und in den automatisierten Tests.
Die häufige Fehlinterpretation, die allein basierend auf dem Namen durchaus nachvollziehbar ist: Jedes Stück Code dürfe nur einmalig existieren - sogar dann, wenn es in verschiedenen Teilen des Codes vorkommt, die voneinander nichts wissen sollten. Wer nur diese falsche Interpretation kennt, sollte sie schnellstmöglich vergessen, denn sie führt zu verstärkter Kopplung (coupling) im Programmcode. Dadurch werden Änderungen nicht nur aufwendiger, sondern es schleichen sich auch leichter Fehler ein.
Single Responsibility Principle (SRP)
Dieses Prinzip ist wahrscheinlich das am häufigsten missverstandene der bekannten SOLID Principles. Laut dem Autor Robert C. Martin, der das Prinzip formuliert hat, liegt es vermutlich am unpassenden Namen: Viele Software-Entwickler*innen interpretieren daraus, dass jedes Modul bzw. jede Klasse nur eine Sache tun soll. Es gibt zwar auch das Prinzip, dass jede Funktion nur eine Sache tun soll, was aber nichts mit dem SRP zu tun hat. Im Gegenteil: Ein Ziel des Prinzips ist Kohäsion, also das Zusammenbringen der Funktionalität, die fachlich oder technisch zusammengehört und für dieselbe Gruppe von (fachlichen oder technischen) "Nutzern" geändert wird. Wer aufgrund dieses Missverständnisses zusammengehörigen Code voneinander trennt, damit jede Klasse oder jedes Modul vermeintlich nur noch "eine Sache tut", erreicht also genau das Gegenteil - und verstößt neben dem SRP auch gleich gegen mehrere andere Prinzipien. Die "Responsibility" (Verantwortlichkeit) liegt nicht darin, was eine Klasse tut, sondern für wen.
Open-Closed Principle (OCP)
Dieses Prinzip (das O in SOLID) hat zum Ziel, dass neue Funktionalität hinzugefügt werden kann, ohne dafür große Mengen des bestehenden Codes anpassen zu müssen. Der häufige Fehler: Mögliche zukünftige Funktionalität "erraten" und den Code schon mal im voraus möglichst flexibel machen. Durch dieses Overengineering wird der Code häufig schwerer verständlich, und ein großer Teil dieser Flexibilität wird dann womöglich nie gebraucht. Stattdessen spricht Robert C. Martin von einer strategic closure ("strategische Hülle") um bestimmte Teile des Codes, die durch bestimmte Codeänderungen nicht beeinflusst werden sollen. Die Codeänderungen werden dadurch lokal gehalten, statt sich durch die Codebasis zu verbreiten.
Fazit
Bei Software-Design-Prinzipien kann man oft den Flüsterpost-Effekt beobachten: Informationen gehen verloren, Menschen fügen ihre eigene Interpretation hinzu, und so verbreiten sich Missverständnisse oft schneller als die richtige Information. Darum empfiehlt es sich bei neu gehörten Prinzipien gelegentlich die originale Quelle nachzulesen, um sein Verständnis zu prüfen - zum Beispiel zeitlose Klassiker wie The Pragmatic Programmer. Und wie bei jedem Skill ist auch beim Software-Design Fingerspitzengefühl und zielorientiertes Vorgehen gefragt - das blinde Befolgen von subjektiven "Prinzipien" ist selten hilfreich. Die besten Software-Designs entstehen durch enge Kollaboration in divers aufgestellten Teams.