SOLID

1) SRP – The Single Responsibility Principle

2) OCP – The Open-Closed Principle

3) LSP – The Liskov Substitution Principle

4) ISP – The Interface Segregation Principle

5) DIP – The Dependency Inversion Principle

„Modul-Level“: zwischen „Code-Level“ und „High-Level Architektur“

(Zusammengefasst führen die SOLID-Prinzipien zu einer höheren Codequalität, indem sie den Code modularer, flexibler und leichter wartbar machen. Dies erleichtert es, neue Funktionen hinzuzufügen, Fehler zu beheben und den Code an neue Anforderungen anzupassen.)

A module should be responsible to one and only one actor.

1. Problem: Eine Klasse hat mehrere Verantwortlichkeiten. Änderungen an einer Verantwortlichkeit können unbeabsichtigte Nebenwirkungen auf andere Verantwortlichkeiten haben.

2. Lösung: Jede Klasse sollte nur eine Verantwortlichkeit haben. Dadurch wird die Klasse einfacher zu verstehen, zu warten und zu ändern.

A software artifact should be open for extension but closed for modification.

1. Problem: Änderungen an bestehenden Klassen führen dazu, dass der bestehende Code angepasst werden muss, was das Risiko von Fehlern erhöht und die Wartung erschwert.

2. Lösung: Klassen sollten so entworfen werden, dass sie durch Hinzufügen von neuem Code erweitert werden können, ohne den bestehenden Code zu ändern. Dies kann durch Verwendung von Abstraktionen und Schnittstellen erreicht werden.

3. Ziel ist es also, das System leicht erweiterbar zu machen, ohne dass die Auswirkungenvon Änderungen zu groß sind.

1. Problem: Unterklassen verhalten sich nicht wie ihre Basisklassen. Dadurch kann es zu unerwarteten Fehlern kommen, wenn Unterklassen anstelle von Basisklassen verwendet werden.

2. Lösung: Unterklassen sollten die gleichen Erwartungen wie ihre Basisklassen erfüllen, sodass sie überall dort verwendet werden können, wo die Basisklasse erwartet wird. Dies bedeutet, dass die Methoden der Unterklassen die gleichen Eingaben akzeptieren und die gleichen Ausgaben liefern sollten wie die Methoden der Basisklasse.

3. Vorteil: Der Code wird zuverlässiger und vorhersagbarer, da Unterklassen überall dort verwendet werden können, wo Basisklassen erwartet werden, ohne dass das System unerwartetes Verhalten zeigt.

1. Problem: Große, umfangreiche Schnittstellen zwingen implementierende Klassen dazu, Methoden zu implementieren, die sie nicht benötigen. Dies führt zu unnötiger Komplexität.

2. Lösung: Schnittstellen sollten so klein wie möglich gestaltet sein, sodass implementierende Klassen nur die Methoden implementieren müssen, die sie tatsächlich benötigen. Dies führt zu klarer und fokussierter Gestaltung.

3. Vorteil: Der Code wird klarer und weniger komplex. Klassen sind einfacher zu implementieren und zu testen, da sie nur die benötigten Methoden enthalten.

The most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions.

1. Problem: Hochrangige Module sind von niederrangigen Modulen abhängig. Änderungen in den niederrangigen Modulen können die hochrangigen Module beeinträchtigen, was die Wartbarkeit und Flexibilität des Systems verringert.

2. Lösung: Sowohl hochrangige als auch niederrangige Module sollten von Abstraktionen abhängen. Abstraktionen sollten nicht von konkreten Implementierungen abhängen. Dies fördert die Entkopplung und ermöglicht es, Module unabhängig voneinander zu ändern.

3. Vorteil: Der Code ist besser modularisiert und entkoppelt, was die Wartbarkeit und Flexibilität erhöht. Module können unabhängig voneinander entwickelt, getestet und ausgetauscht werden.