Clean-Code.md

@@ -6,10 +6,29 @@ Ein zentrales Prinzip, das wir in unserem Projekt umgesetzt haben, ist das DRY-P
 
 Seperation of concerns ist ein essenzielles Prinzip um bessere Wartbarkeit, Erweiterbarkeit, Tests und Verständnis des Systems zu garantieren. Mit der klaren Trennung in Controller, Service und Repositorys haben wir sichergestellt, dass jede Schicht eine eigene Aufgabe hat. Das sorgt für weniger Abhängigkeiten und erhöht die Code-Qualität.
 
+**KISS: Keep it simple stupid**
+
+Durch die Verwendung von einfacher und klarer Logik und den Verzicht auf unnötig komplexe Abstraktionen haben wir unseren Code Lesbar und Verständlich gehalten. Außerdem haben wir darauf geachtet nur die notwendigen Features einzubauen und nur die Funktionen implementiert die auch wirklich gebraucht werden.
+
+
+## SOLID Prinzipien
+
 **Single Responsibility Principle**
 
 Wir haben in unserem Projekt darauf geachtet, dass jede Klasse und Methode genau eine Aufgabe hat um zu komplexe Strukturen und Nebeneffekte zu vermeiden. Dadurch stellen wir sicher, dass es nicht zu viele Abhängigkeiten zwischen verschiedenen Methoden gibt und der Code besser entkoppelt ist.
 
-**KISS: Keep it simple stupid**
+**Open-Closed Principle**
 
-Durch die Verwendung von einfacher und klarer Logik und den Verzicht auf unnötig komplexe Abstraktionen haben wir unseren Code Lesbar und Verständlich gehalten. Außerdem haben wir darauf geachtet nur die notwendigen Features einzubauen und nur die Funktionen implementiert die auch wirklich gebraucht werden.
+Wir haben unser System so gestaltet, dass bestehender Code nicht geändert, sondern durch Erweiterungen ergänzt werden kann. Dies haben wir durch die konsequente Nutzung von Schnittstellen und abstrakten Klassen erreicht. Dadurch können neue Funktionen einfach hinzugefügt werden, ohne den bestehenden Code anzupassen, was die Wartbarkeit und Stabilität unseres Systems erheblich verbessert.
\ No newline at end of file
+
+**Liskov Substitution Principle (LSP)**
+
+Beim Design unserer Klassenhierarchien haben wir darauf geachtet, dass Subklassen jederzeit anstelle ihrer Basisklassen verwendet werden können, ohne das erwartete Verhalten zu verändern. Durch die Einhaltung dieses Prinzips gewährleisten wir, dass unser Code flexibel bleibt und neue Implementierungen problemlos integriert werden können, ohne bestehende Logik zu beeinträchtigen.
+
+**Interface Segregation Principle (ISP)**
+
+Um unnötige Abhängigkeiten zu vermeiden, haben wir darauf geachtet, dass unsere Schnittstellen nur die Methoden enthalten, die für die jeweilige Funktionalität tatsächlich benötigt werden. 
+
+**Dependency Inversion Principle (DIP)**
+
+Wir haben unser System so aufgebaut, dass High-Level-Module nicht direkt von Low-Level-Modulen abhängen, sondern beide von Abstraktionen. Durch den gezielten Einsatz von Dependency Injection konnten wir sicherstellen, dass unsere Komponenten flexibel austauschbar sind. Dies erhöht nicht nur die Testbarkeit unseres Codes, sondern ermöglicht uns auch eine einfachere Anpassung und Erweiterung der Funktionalitäten.