2.8 KiB
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
ferzeugt werden - Objekte die
fals 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