# 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 * Hohe Kohäsion * OCP: Open Closed Principle * Open for Extension/Closed for Modification -> Vertrauen in Code steigt * LSP: Liskov Substitution Principle * Eine Subklasse soll immer Ersatz für ihre Superklasse sein * ISP: Interface Segregation Principle * Ein Klient sollte nicht gezwungen sein von Methoden abzuhänge, die er nicht benutzt * DIP: Dependency Inversion Principle * Reduzierte Kopplung: Man sollte niemals von etwas konkreten abhängen sondern immer von Interfaces --- # Kein Code < Schlechter Code