Fachinformatiker: SOLID-Prinzipien der OOP – einfach erklärt

Wichtige Punkte:

1. 1**S - Single Responsibility Principle (Prinzip der einzigen Verantwortung):** Eine Klasse sollte nur einen Grund zur Änderung haben. Das bedeutet, sie sollte nur eine einzige Aufgabe oder Verantwortung haben. Stell dir vor, ein Koch soll nicht nur kochen, sondern auch die Buchhaltung machen – das wird chaotisch! Besser: Ein Koch kocht, ein Buchhalter macht die Buchhaltung.
2. 2**O - Open/Closed Principle (Prinzip der Offenheit und Geschlossenheit):** Software-Entitäten (Klassen, Module, Funktionen) sollten offen für Erweiterungen, aber geschlossen für Modifikationen sein. Das heißt, du kannst neue Funktionen hinzufügen, ohne den bestehenden, funktionierenden Code ändern zu müssen. Denk an ein Smartphone: Du kannst neue Apps installieren (erweitern), ohne das Betriebssystem ändern zu müssen (geschlossen für Modifikationen).
3. 3**L - Liskov Substitution Principle (Liskovsches Substitutionsprinzip):** Objekte eines Untertyps müssen durch Objekte ihres Basistyps ersetzt werden können, ohne die Korrektheit des Programms zu beeinträchtigen. Einfach gesagt: Wenn du eine 'Katze' hast, die von 'Tier' erbt, dann sollte alles, was mit 'Tier' funktioniert, auch mit 'Katze' funktionieren, ohne dass das Programm spinnt. Eine Katze ist ein Tier, aber ein Tier ist nicht unbedingt eine Katze.
4. 4**I - Interface Segregation Principle (Prinzip der Schnittstellensegregation):** Clients (Klassen, die Interfaces nutzen) sollten nicht gezwungen werden, von Interfaces abzuhängen, die sie nicht verwenden. Besser sind viele kleine, spezifische Interfaces als ein großes, 'fettes' Interface. Wenn du ein Werkzeug brauchst, willst du nicht den ganzen Werkzeugkasten mitschleppen, sondern nur den Schraubenschlüssel.
5. 5**D - Dependency Inversion Principle (Prinzip der Abhängigkeitsumkehr):** Module auf hoher Ebene sollten nicht von Modulen auf niedriger Ebene abhängen. Beide sollten von Abstraktionen (Interfaces) abhängen. Abstraktionen sollten nicht von Details abhängen. Details sollten von Abstraktionen abhängen. Das bedeutet, dass du nicht direkt von konkreten Implementierungen abhängig sein solltest, sondern von Schnittstellen. Dein Auto braucht einen 'Motor' (Abstraktion), nicht einen 'VW-Motor' (Detail). So kannst du den Motor leichter austauschen.