Das erste Solid-Prinzip ist das “Single-Responsibility-Prinzip”. Es besagt, dass eine Klasse nie mehr als eine Verantwortlichkeit bzw. Aufgabe haben sollte. Änderungen haben somit möglichst wenig Auswirkungen und einzelne „Werkzeuge“ können im Code leichter gefunden werden.

Code, der diesem Prinzip entspricht, ist keineswegs umfangreicher, sondern nur auf mehrere kleine Klassen verteilt. Der Aufwand bei der Implementierung ist daher kaum höher, während zukünftige Anpassungen, vor allem die von Kollegen, deutlich vereinfacht werden.

Das zweite Prinzip ist das “Open-Closed-Prinzip”. Es empfiehlt grundsätzlich, bestehenden Code nur noch zu erweitern statt zu verändern. Möglich wird das durch Vererbungen oder den Einsatz von Interfaces. Wichtig ist das vor allem, wenn in fertigem bestehenden Code neue Fehler vermieden werden sollen. Neue Anforderungen an den Code sollten also im Optimalfall keine Codeänderungen, sondern ausschließlich neuen Code zur Folge haben.

Das „Liskovsche Substitutionsprinzip“ an Platz 3 ist das wohl am häufigsten missachtete Prinzip. Es sagt aus, dass abgeleitete Klassen die Funktionalität ihrer Basis nur erweitern, nicht jedoch verändern oder einschränken dürfen. Die Basisklasse muss jederzeit durch eine ihrer Ableitungen ersetzt werden können. Das Problem bei diesem Prinzip ist, dass es häufig als Widerspruch zur Abstrahierung von Klassen verstanden wird. Dieses Problem wird am folgenden Beispiel deutlich: Eine Ellipse ist ein grafisches Element und ein Kreis ist eine Ellipse. Diese „ist-ein“ Beziehungen beschreiben eine simple Vererbung, die auch so nicht falsch ist. Besitzt jedoch die Oberklasse grafisches Element eine Methode, die die Skalierung der Achsen erlaubt, dann widerspricht diese Hierarchie bereits dem Liskovschen Substitutionsprinzip. Denn ein Kreis darf diese Methode so nicht unterstützen, da es dann kein Kreis mehr wäre.

Das „I“ in SOLID steht für das Interface-Segregation-Prinzip und beschreibt die Aufteilung von Interfaces in kleinere Interfaces, die dann wirklich nur noch eine einzige Funktion abdecken. Ziel ist es, dass Klassen nicht von Interfaces abhängig sein sollten, die sie nicht oder nur teilweise brauchen. Es dient der besseren Erweiterbarkeit und ermöglicht eine sehr geringe Änderung am Code, wenn sich Anforderungen ändern.

Das letzte Prinzip beschreibt unter dem Namen Dependency-Inversion-Prinzip die Regeln der Abhängigkeiten. So sollen konkrete Module immer nach oben hin von abstrakten Klassen abhängig sein. Niemals anders herum. Das verhindert vor allem zirkuläre Abhängigkeiten. Verstößt man gegen dieses Prinzip, kann man kaum noch die nötigen Änderungen abschätzen, wenn man an der Klasse unterer Ebene etwas ändert, weil von ihr ggf. eine Klasse höherer Ebene ableitet, welche wiederum die Basis für zahlreiche weitere Klassen bilden kann.

Fazit:

Gemäß aller Recherche gibt es keinen Grund, die genannten Prinzipien aus heutiger Sicht infrage zu stellen. Obwohl es, wie gesagt, unzählige weitere Prinzipien gibt, bilden die fünf genannten eine gute Basis, an der man sich für die Erstellung von sauberem Code orientieren kann. Trotzdem kann nicht jedes Prinzip in jedem Szenario Anwendung finden und es kann vorkommen, dass der Verstoß gegen einzelne Prinzipien zwingend erforderlich ist.

Vereinfacht wird die Umsetzung der Prinzipien durch die heutigen IDEs und Erweiterungen wie Resharper, in denen man Regeln erstellen kann, um die Einhaltung zu forcieren und Flüchtigkeitsfehler zu vermeiden.

Beachtet man also diese und andere meist recht einfache Prinzipien, vereinfacht man nicht nur sich, sondern vor allem Kollegen die Arbeit, die sich schneller in den Code einfinden und diesen verändern, erweitern oder warten können.

Dieser quiTeq-Tipp stammt von Kevin Köppe, QUIBIQ Berlin.