SOLID Principles leicht erklärt
Clean Code – ist für viele Programmierenden eines der wichtigsten Gebote. Warum? Ein sauberer Code ermöglicht nicht nur eine bessere Übersicht, mehr Flexibilität und einfache Wartung – er ist on top auch noch leicht verständlich für andere Programmierenden, die mit daran arbeiten bzw. sich mit dem Code befassen. Eine Möglichkeit, wie man genau das erreicht, sind die SOLID Prinzipien. In unserer Jungle Academy, unserem internen Format von Entwickelnden für Entwickelnde, wurden die SOLID Principles vorgestellt. Sie wollen sich erstmals im Coden versuchen? Dann beachten Sie auf jeden Fall die SOLID Principles. Was diese sind erklären wir Ihnen in diesem Artikel.
Die SOLID Principles bilden eine wichtige Grundlage für Clean Code. Eingeführt wurden die SOLID Prinzipen von Robert C. Martin aka Uncle Bob, allerdings stammen nicht alle Prinzipien von ihm. Warum man sich daran halten sollte? Easy – die SOLID Prinzipien helfen uns dabei:
- Besseren Code zu schreiben
- Leicht verständliches Software-Design aufzubauen
- Vorhandenen Code einfach zu pflegen und leicht zu erweitern
But first: Was ist überhaupt ein Prinzip in der Softwareentwicklung?
Prinzipen sind Regeln oder Gesetze, die bei der Entwicklung immer einzuhalten sind – man könnte es mit der einfachsten Matheregel vergleichen: Punkt vor Strich. Man könnte auch sagen: Sie sind dazu da, um Probleme zu lösen oder zu vereinfachen. Außerdem helfen sie Ihnen und Ihrem Team dabei, dass die resultierende Software bestimmte Eigenschaften besitzt. Die Eigenschaften sind abhängig von dem Prinzip.
Was bedeuten die SOLID Principles ausgeschrieben?
Single Responsibility Principle
Open-Closed-Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle
TRIGGERWARNUNG: Es wird technisch!
Single Responsibility Principle
Ein System hat nur eine Aufgabe
Eine Klasse sollte nur eine Verantwortung haben und es sollte nur einen Grund geben, weshalb man die Klasse ändern möchte. Do one thing and do it well! Das Ergebnis ist eine Architektur, die klar, verständlich und besser wartbar ist. Befolgt man das Single Responsibility Principle nicht, werden potenzielle Wartungsprobleme in der Software geschaffen. So können etwa andere Bereiche und Funktionalitäten dadurch negativ beeinflusst werden.
Vorteile des Single Responsibility Principle:
✔️ Einfache Wartung: Da man für jede Klasse einen klaren Zweck definiert, ist diese einfacher zu warten, weil sie kleiner und übersichtlicher ist
✔️ Vermeidung von Seiteneffekten in Bezug auf andere Verantwortlichkeiten bei Änderungen
✔️ Bessere Zusammenarbeit: Die Arbeit in Programmierteams kann besser aufgeteilt werden, denn jeder Programmierende kann dann an einer Klasse arbeiten, für die er/sie zuständig ist.
✔️ Hält Abhängigkeiten bei der Wiederverwendung von Klassen auf ein Minimum
✔️ Durch kleine Klassen wird die Fehlerbehebung stark vereinfacht
✔️ Möglichkeit, klare und aussagekräftige Klassennamen zu vergeben, da jede Klasse eine Verantwortung hat
✔️ Entkopplung von Implementierungen auf der Grundlage dessen, was sich wahrscheinlich gemeinsam ändern wird
✔️ Aufwand für Entwicklung und Tests wird gesenkt
Open-Closed Principle
Module sollten offen für Erweiterungen, aber geschlossen für Modifizierung (Veränderungen) sein
Im Grunde genommen geht es bei dem Open-Closed Principle darum, strategisch vorzugehen, denn es fordert, dass geschriebener Code (der auch getestet wurde) nicht mehr verändert werden soll bzw. den Softwareentwurf so zu konstruieren, dass Änderungen mitgetragen werden können, ohne das System komplett umzubauen.
Wie das erreicht werden kann? Durch Vererbung oder, indem man das Modul mit einem Interface (Schnittstellen) versieht. Dadurch wird das bereits vorhandene Verhalten des Moduls nicht verändert, sondern lediglich um zusätzliche Funktionen oder Daten erweitert.
Vorteile des Open-Closed Principle:
✔️ Fehler werden vermieden, da bereits geschriebener Code in Ruhe gelassen wird
✔️ Software wird wartbarer
✔️ Wiederverwendung durch den Entwurf stabiler Schnittstellen
Liskov Substitution Principle
Soll eine abgeleitete Klasse implementiert werden, muss die Basisklasse erweitert werden, ohne das Verhalten der Basisfunktion zu verändern
Einfacher gesagt: Subklassen müssen sich verhalten wie Basisklassen. Das Liskov Substitution Principle ist eigentlich ein Ersetzbarkeitsprinzip. Hierbei geht es um die Austauschbarkeit über Klassenvererbungshierachien hinweg: Subklassen müssen sich wie Basisklassen verhalten. Schauen Sie sich die Grafik mit dem Quadrat und dem Rechteck an: Zwischen Quadraten und Rechtecken gibt es eine Beziehung: Man kann sagen, jedes Quadrat ist ein Rechteck, aber nicht jedes Rechteck ist ein Quadrat. Sie merken schon, in der Programmierung würde diese Vererbungsbezieung nicht funktionieren.
Wie kann man das also in der Programmierung lösen? Statt der Vererbung von Quadrat und Rechteck führt man eine dritte Klasse ein, von der sowohl Quadrat als auch Rechteck ableiten. Somit sind Quadrat und Rechteck nur noch über die neue dritte Klasse miteinander gekoppelt.
Vorteile des Liskov Substitution Principle:
✔️ Sicherheit, dass eine Implementierung ausgetauscht werden kann, ohne ihr Verhalten zu ändern
Interface Segregation Principle
Jede Klasse sollte nur auf einen Aspekt bzw. Thema gerichtet sein
Das Interface Segregation Principle beschäftigt sich mit der Trennung bzw. Entkopplung von Klassen. Beim Open-Closed Principle haben wir gelernt, mit Interfaces zu arbeiten. Jedoch sind auch Interfaces nicht problemlos, da sie meist dazu neigen, immer größer und größer zu werden. Das führt dazu, dass es immer schwieriger wird, eine vollständige Implementierung bereitzustellen, da immer mehr Code hinzugefügt werden muss.
Die Lösung? Interfaces erst gar nicht groß werden lassen und sie schon vorher in viele kleine Interfaces teilen. So können nach außen viel zielgerichtetere Interfaces definiert werden.
Vorteile des Interface Segregation Principle:
✔️ Vereinfacht Wiederverwendung, Tests und Wartung durch Aufteilung der Verantwortlichkeiten
✔️ Isoliert Klassen vor Fehlern durch die Einführung klarer Grenzen
✔️ Ermöglicht das Ersetzen von Funktionen, ohne dass verwandte Klassen verstanden werden müssen
✔️ Senkt die kognitive Belastung durch Isolierung von Themen
✔️ Fokussiert die Aufmerksamkeit auf einen einzigen Aspekt
Dependency Inversion Principle
Klassen höherer Ebenen sollten nicht von Klassen niedrigerer Ebenen abhängen
Die Idee dahinter: Mängel aufräumen. Die bisher genannten Prinzipien haben Klassen beschrieben, Schnittstellen von Klassen erstellt oder Klassen erweitert. Jetzt gibt es noch ein Problem: Die Klassen sind noch voneinander abhängig. Was also tun? Das Dependency Inversion Principle schlägt hierfür vor, ein Interface einzubauen, um zwei Klassen voneinander zu entkoppeln. Somit verweist die erste Klasse auf das Interface und die zweite Klasse implementiert das Interface, sodass die zweite Klasse (weil sie das passende Interface enthält) in die erste Klasse als Parameter eingesetzt werden kann.
Vorteile des Dependency Inversion Principle:
✔️ Ermöglicht die Wiederverwendbarkeit von High-Level-Klassen durch Einfügen von Klassen
✔️ Da Implementierungen ausgetauscht werden können, werden Änderungen auf niedriger Ebene erleichtert
✔️ Code-Vereinfachung durch einheitliches Arbeiten mit alternativen Klassen
✔️ Verbessert die Prüfbarkeit
Fazit? Sounds SOLID!
Sie sehen, die SOLID Prinzipen vereinfachen das Codieren und helfen Ihnen zu einem sauberen Code. Auch für unsere Programmierenden bei mmmake spielen sie eine zentrale Rolle in der alltäglichen Arbeit. Stephan Weissenberger, Unit Lead Softwareentwicklung Lemures:
“Die SOLID Prinzipien bilden das Fundament unserer Arbeit. Sie sind leicht zu erlernen, aber schwer zu meistern. Sie sind einer der ersten Inhalte, die wir jungen Entwicklerinnen und Entwicklern vermitteln, um ihnen den richtigen Einstieg in die Softwareentwicklung zu bieten. Heute weisen wir uns auch nach mehrjähriger Erfahrung immer wieder mit einem Grinsen auf Verstöße gegen diese Prinzipien hin. Der Andere stöhnt bei einem Anfängerfehler erwischt worden zu sein und korrigiert seine Arbeit.”