Warum Designprinzipien nicht immer die beste Antwort sind

Designprinzipien gehören zu den Themen, über die man in der Java-Welt relativ früh stolpert. Irgendwann tauchen dann Begriffe wie KISS, DRY, YAGNI oder SOLID auf, und plötzlich sieht es so aus, als gäbe es für jede Zeile Code eine feste Regel. Das Problem daran ist nicht, dass diese Prinzipien falsch wären. Das Problem ist eher, dass sie oft wie Naturgesetze behandelt werden, obwohl sie in der Praxis eher Orientierungshilfen sind.

Gerade am Anfang ist das schnell frustrierend. Du liest an einer Stelle, dass du Wiederholungen unbedingt vermeiden sollst. An anderer Stelle heißt es, du sollst nicht zu früh abstrahieren. Dann liest du, dass Klassen nur genau eine Verantwortung haben sollen, während echte Anforderungen oft dafür sorgen, dass eine Klasse am Ende trotzdem mehrere Dinge koordiniert. Genau an dem Punkt lohnt sich ein ruhiger Blick auf das Thema. Designprinzipien sind wichtig. Aber sie sind nicht die ganze Wahrheit.

Warum es Designprinzipien überhaupt gibt

Designprinzipien sind nicht entstanden, damit Code theoretisch schön aussieht. Sie sind aus echten Problemen im Alltag entstanden. Ein Projekt wächst, Anforderungen ändern sich, mehrere Entwickler arbeiten gleichzeitig daran, und plötzlich wird jede kleine Änderung unnötig teuer. Prinzipien helfen dabei, solche Probleme früher zu erkennen oder ganz zu vermeiden.

Nehmen wir KISS, also "Keep It Simple, Stupid". Dahinter steckt keine Magie, sondern etwas sehr Bodenständiges: einfacher Code ist leichter zu lesen, zu testen und zu ändern. Wenn du für ein kleines Problem drei Abstraktionsebenen, zwei Interfaces und ein generisches Utility baust, wirkt das vielleicht clever, macht die Sache aber oft nur schwerer.

Ein einfaches Beispiel wäre so etwas:

public BigDecimal calculateTotal(BigDecimal price, int quantity) {
    return price.multiply(BigDecimal.valueOf(quantity));
}

Das ist nicht spektakulär, aber klar. Jeder versteht sofort, was passiert. Genau darum geht es oft bei guten Prinzipien: nicht um Eleganz auf dem Papier, sondern um Verständlichkeit im Alltag.

Auch DRY, also "Don't Repeat Yourself", hat einen sinnvollen Kern. Doppelte Logik an mehreren Stellen sorgt früher oder später dafür, dass Änderungen vergessen werden. Trotzdem heißt DRY nicht, dass jede ähnliche Zeile sofort in eine gemeinsame Hilfsmethode gezogen werden muss. Manchmal sind zwei fast gleiche Stellen erstmal völlig okay, solange noch nicht klar ist, ob sie wirklich dieselbe fachliche Bedeutung haben.

Warum sich Prinzipien in der Praxis auch mal widersprechen

Genau hier wird es spannend: Viele Prinzipien funktionieren einzeln gut, geraten aber gemeinsam schnell in Konflikt. DRY sagt dir, Wiederholungen zu vermeiden. YAGNI, also "You Aren't Gonna Need It", erinnert dich daran, nichts auf Vorrat zu bauen. In der Praxis heißt das oft: Solltest du jetzt schon abstrahieren, um Dopplungen zu vermeiden, oder lieber noch warten, bis klar ist, dass die Gemeinsamkeit wirklich stabil ist?

Beides kann richtig sein. Und genau deshalb bringt es wenig, Prinzipien wie starre Regeln zu behandeln.

Ein typischer Fall ist eine Methode, die anfangs zweimal fast gleich vorkommt. Die spontane Reaktion ist oft, sofort eine gemeinsame Utility-Methode zu bauen. Das kann sinnvoll sein. Es kann aber auch dazu führen, dass du zwei fachlich unterschiedliche Abläufe zu früh zusammenklebst. Dann sparst du heute ein paar Zeilen und handelst dir morgen unnötige Komplexität ein.

Ähnlich ist es bei SOLID. Das Single-Responsibility-Prinzip wird oft so verstanden, als dürfe eine Klasse nur genau eine einzige Sache tun. In echter Software ist das aber selten so sauber. Eine Service-Klasse darf durchaus einen fachlichen Ablauf koordinieren, auch wenn darin mehrere Schritte passieren. Wichtig ist eher, dass die Klasse eine klare fachliche Aufgabe hat und nicht wahllos alles einsammelt.

So ein Service ist zum Beispiel völlig normal:

public void registerUser(User user) {
    validate(user);
    userRepository.save(user);
    mailService.sendWelcomeMail(user);
}

Diese Methode validiert, speichert und verschickt danach eine Mail. Rein mechanisch sind das mehrere Schritte. Fachlich gehört das trotzdem zusammen, weil es alles Teil des Registrierungsprozesses ist. Das ist nicht automatisch ein Verstoß gegen gutes Design.

Nicht jedes Prinzip ist in jedem Projekt gleich wichtig

Ein weiterer Punkt, der oft untergeht: Manche Prinzipien kommen in der realen Welt deutlich seltener bewusst zum Tragen, als Bücher oder Tutorials vermuten lassen. Nicht weil sie schlecht wären, sondern weil Projekte meist unter echten Rahmenbedingungen laufen. Termine, Legacy-Code, bestehende Architektur, Teamgewohnheiten oder technische Altlasten spielen eben mit rein.

In einem frischen Demo-Projekt kannst du vieles ideal umsetzen. In einer gewachsenen Java-Anwendung mit WildFly, Maven-Modulen, älteren Schnittstellen und historisch gewachsenen Datenmodellen sieht die Sache oft anders aus. Dann ist die beste Lösung nicht die theoretisch sauberste, sondern die, die den Code heute besser macht, ohne an fünf anderen Stellen etwas kaputt zu machen.

Das heißt nicht, dass Prinzipien egal sind. Im Gegenteil. Du solltest grob wissen, warum es sie gibt und welches Problem sie adressieren. KISS hilft gegen unnötige Komplexität. DRY schützt vor verstreuter Logik. YAGNI bremst vorschnelles Vorausbauen. SOLID kann dir helfen, Abhängigkeiten und Verantwortlichkeiten sauberer zu schneiden. Aber du musst nicht jede Entscheidung mit einem Akronym rechtfertigen.

Wichtiger ist oft, dass du dir ein paar einfache Fragen stellst: Ist der Code verständlich? Kann ich ihn morgen noch ohne Bauchschmerzen ändern? Ist die Struktur für den aktuellen Anwendungsfall passend? Oder baue ich gerade etwas, das nur in der Theorie schön aussieht?

Designprinzipien funktionieren am besten als Denkwerkzeug. Sie helfen dir, Probleme bewusster zu sehen. Sie nehmen dir aber nicht das Nachdenken ab.

Fazit

Designprinzipien sind sinnvoll, weil sie aus echten Problemen entstanden sind. Es ist gut, sie zu kennen und grob einordnen zu können. Gerade in Java-Projekten helfen sie dir dabei, Code lesbarer, robuster und wartbarer zu machen. Nur solltest du sie nicht wie unverrückbare Gesetze behandeln.

Manche Prinzipien widersprechen sich. Manche sind in bestimmten Situationen wichtiger als andere. Und manche kommen im Alltag weniger spektakulär vor, als es auf den ersten Blick wirkt. Gute Software entsteht deshalb nicht dadurch, dass du jedes Prinzip maximal streng befolgst. Gute Software entsteht eher dann, wenn du den Kontext verstehst und bewusst entscheidest, was gerade sinnvoll ist.

Am Ende ist sauberes Design keine Checkliste, die du einfach abhaken kannst. Es ist eher eine Frage von Verständnis, Erfahrung und gesundem Pragmatismus. Genau deshalb lohnt es sich, die Prinzipien zu kennen, ohne sie zu idealisieren.