Die SOLID-Prinzipien sind eine Sammlung von fünf grundlegenden Prinzipien der objektorientierten Programmierung, die dazu dienen, den Code wartbar, erweiterbar und verständlich zu halten. Diese Prinzipien wurden von Robert C. Martin entwickelt und bilden die Grundlage für gutes Softwaredesign. Im Folgenden werde ich die fünf Prinzipien vorstellen und durch Beispiele erläutern.
1. Single Responsibility Principle (SRP)
Das Prinzip besagt, dass eine Klasse nur eine einzige Verantwortlichkeit haben sollte. Das bedeutet, sie sollte nur einen Grund zur Änderung haben.
Beispiel:
Angenommen, wir haben eine Klasse Rechnungsstellung, die sowohl die Rechnung generiert als auch den Versand der Rechnung per E-Mail übernimmt. Diese Klasse verstößt gegen das SRP, da sie zwei unterschiedliche Verantwortlichkeiten hat. Eine bessere Lösung wäre, eine separate Klasse Rechnungsversand zu erstellen, die sich nur um den Versand kümmert.
2. Open/Closed Principle (OCP)
Eine Klasse sollte offen für Erweiterungen, aber geschlossen für Änderungen sein. Das bedeutet, man sollte bestehende Klassen nicht direkt ändern, sondern neue Funktionalitäten durch Vererbung oder Schnittstellen hinzufügen.
Beispiel:
Stellen Sie sich vor, Sie haben eine Klasse Berechnungsstrategie, die verschiedene Berechnungsarten enthält. Wenn Sie eine neue Berechnungsstrategie hinzufügen wollen, sollten Sie keine bestehenden Klassen ändern, sondern eine neue Klasse erstellen, die von einer abstrakten Klasse oder Schnittstelle erbt.
3. Liskov Substitution Principle (LSP)
Nach diesem Prinzip sollte eine Instanz einer abgeleiteten Klasse überall dort verwendet werden können, wo eine Instanz der Basisklasse erwartet wird, ohne dass das Verhalten des Programms sich verändert.
Beispiel:
Wenn Sie eine Basisklasse Vogel haben und eine abgeleitete Klasse Pinguin, dann sollte der Pinguin genauso wie der Vogel flugfähig sein, es sei denn, der Pinguin ist nicht flugfähig. Andernfalls könnten Fehlfunktionen auftreten, wenn man ein Objekt vom Typ Vogel durch ein Objekt vom Typ Pinguin ersetzt.
4. Interface Segregation Principle (ISP)
Das Prinzip besagt, dass ein Client nicht gezwungen werden sollte, Schnittstellen zu implementieren, die er nicht benötigt. Statt einer großen Schnittstelle sollte man mehrere kleinere, spezialisierte Schnittstellen anbieten.
Beispiel:
Stellen Sie sich vor, Sie haben eine Schnittstelle Drucker, die sowohl Drucken() als auch Scannen() definiert. Ein einfacher Drucker muss jedoch nur die Methode Drucken() implementieren. Eine bessere Lösung wäre, die Schnittstelle in Drucker und Scanner zu unterteilen, sodass der Drucker nur das Drucken benötigt.
5. Dependency Inversion Principle (DIP)
Hohe Klassen sollten nicht von niedrigen Klassen abhängen, sondern beide sollten von Abstraktionen abhängen. Dies bedeutet, dass wir Abstraktionen verwenden sollten, anstatt konkrete Implementierungen direkt zu nutzen.
Beispiel:
Wenn Sie eine Klasse Bestellservice haben, die direkt von einer Klasse Datenbank abhängt, dann verstößt diese Implementierung gegen das DIP. Stattdessen sollten Sie eine Schnittstelle wie Datenbankzugriff einführen, die sowohl von Bestellservice als auch von einer konkreten Implementierung wie MySQLDatenbank abhängt. Dadurch wird der Bestellservice nicht direkt an die konkrete Implementierung der Datenbank gebunden.
Zusammenfassend lässt sich sagen, dass die SOLID-Prinzipien eine wichtige Grundlage für sauberen und wartbaren Code bieten. Sie helfen Entwicklern, flexible und erweiterbare Softwarearchitekturen zu schaffen, die einfach zu testen und zu pflegen sind.
Auch lesenswert: SOLID: Prinzip in der Programmierung