Finish OO design

oo_design.md

@@ -7,3 +7,78 @@ footer: Henri Burau
 -->
 
 # Objektorientierter Entwurf
+
+---
+
+# Grundlagen
+
+Software verändert sich regelmäßig. Diese Änderungen sollten sich so einfach wie möglich umsetzen lassen. Dabei hilft ein guter Objektorientierter Entwurf.
+
+---
+
+# Zuständigkeiten
+
+Ein Objekt in der Objektorientierung soll immer für genau eine Aufgabe verantwortlich sein (engl. "Seperation of Concerns").
+
+--- 
+
+# Kopplung
+
+Die Abhängigkeiten zwischen den unterschiedlichen Objekten soll so gering wie möglich sein. Dabei helfen vor allem Interfaces. Es gibt zwei Arten von Kopplung auf die wir achten müssen:
+
+* Explizite Kopplung: Sind zur Übersetzungszeit klar (Methodenaufrufe etc.).
+* Implizite Kopplung: Es wird sich auf Interna verlassen die nirgendwo spezifiziert sind (z.B. Sortierung).
+
+---
+
+# Zyklenvermeidung
+
+Es sollte unter den Objekten keine zyklischen Abhängigkeiten geben. Stattdessen sollte eine klare Hierarchie der Klassen bestehen.
+
+--- 
+
+# Law of Demeter
+
+"Talk to friends not to strangers"
+
+Eine Methode `f` in Klasse `C` sollte nur Methoden aufrufen aus:
+* `C`
+* Objekte die von `f` erzeugt werden
+* Objekte die `f` als Paramter übergeben werden
+* Exemplarvariablen von `C`
+
+Vermieden werden sollen sind lange Aufrufketten wie man das in Java häufig sieht.
+
+---
+
+# Kohäsion
+
+Ergänzend zu den Zuständigkeiten. Die Kohäsion ist der Grad der Aufgaben die eine Softwareeinheit erfüllt. Bei hoher Kohäsion ist ein Objekt genau für eine Aufgabe zuständig.
+
+---
+
+# Geeignete Bezeichner
+
+Konkrete Klasse sollten durch ein Substantiv benennbar sein. Methoden sollten durch ein treffendes Verb benennbar sein. Die Bezeichner sollten konsistent im ganzen System sein.
+
+---
+
+# Don't repeat yoursef (DRY)
+
+Quelltext sollte nicht an mehreren Stellen eines Systems identisch vorhanden sein. Das ist ein Zeichen von schlechten Code.
+
+---
+
+# Gottklassen
+
+Beinhaltet eine Klasse plötzlich 90% des Quelltextes dann ist das ein Anti-Pattern (oder Code-Smell). Eine solche "Gottklasse" ist ein Zeichen für einen schlechten Softwareentwurf, da wir niedrige Kohäsion haben.
+
+---
+
+# SOLID
+
+* SRP: Single Responsibility Principle
+* OCP: Open Closed Principle
+* LSP: Liskov Substitution Principle
+* ISP: Interface Segregation Principle
+* DIP: Dependency Inversion Principle