Programmierparadigmen

Programmierparadigmen.md

@@ -137,6 +137,65 @@ Skalierbarkeit/Wartbarkeit -> Durch Einführung OOP
 
 
 
+### SOLID
+
+# Separations of Concern
+
+Eine Klasse sollte nur für eine Funktion verantwortlich sein.
+
+# Open/Closed Principle
+
+Offen für Erweiterungen, aber geschlossen für Modifikationen.
+
+
+# Liskov Substitution Principle
+
+Objekte einer abgeleiteten Klasse sollte ohne, dass die Funktionalität des Programms eingeschränkt wird, anstelle von Objekten der Basisklasse verwendet werden können.
+
+# Interface Segregation Principle
+
+Clients sollten nicht von Schnittstellen abhängig sein, welche nicht verwendet werden.
+
+
+# Dependency Inversion Principle
+
+Module sollten nicht von einander abhänig sein, sondern von abstrakten Schnittstellen.
+
+
+
+
+
+
+### STUPID
+
+# Singelton
+
+Es wird nur ein Objekt in einer Klasse erzeugt, wenn diese global zur Verfügung stehen, kann das die Testbarkeit beeinträchtigen.
+
+# Tight Coupling
+
+Teile die nichts miteinander zu tun haben, sind dennoch eng miteinander verbunden. Dies sollte nicht geschehen.
+
+# Untestability
+
+Untestbarkeit z.B. aufgrund von Tight Coupling, was zu Qualitätsverlust des Codes führen kann.
+
+# Premature Optimization
+
+Man sollte erst etwas Optimieren, wenn es auch nötig ist, sonst verschwendet man viel Zeit.
+
+# Indescriptive Naming
+
+Wenn man etwas ungenau benennt, kann das für andere Programmierer, die den Code ansehen, Probleme mit der Nachvollziehbarkeit machen.
+
+# Duplication
+
+Man sollte denselben Code nicht doppeln, da man jedes mal, wenn man etwas am Original verändert, auch bei den gedoppelten Codes die Veränderung vornehmen muss.
+
+
+
+
+