94 lines
2.8 KiB
Markdown
94 lines
2.8 KiB
Markdown
<!--
|
|
title: Object Orientated Design
|
|
description: Folien für Object Orientated Design in Programmieren 2
|
|
url: https://git.henriburau.de/tutorien/programmieren-2
|
|
header: Programmieren 2 **Tutorium**
|
|
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
|
|
* 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
|