| Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung | Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung |
| faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 16:05] – [Warum verteilt man die Funktionalität und den Code auf mehrere Klassen?] sbel | faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 16:05] – [Wann ist ein Klassenentwurf "gut"?] sbel |
|---|
| * **Neue Objekte** können durch **neue Klassen** ein ein Modell eingefügt werden - du willst Hindernisse auf dem Spielfeld? Kein Problem mit der zusätzlichen "hindernis"-Klasse. | * **Neue Objekte** können durch **neue Klassen** ein ein Modell eingefügt werden - du willst Hindernisse auf dem Spielfeld? Kein Problem mit der zusätzlichen "hindernis"-Klasse. |
| |
| ==== Wann ist ein Klassenentwurf "gut"? ==== | ===== Wann ist ein Klassenentwurf "gut"? ===== |
| |
| Ein Klassenentwurf ist also "gut", wenn er die oben genannten Vorteile maximal unterstützt - hierführ kann man zwei Eigenschaften des Entwurfs betrachten: | Ein Klassenentwurf ist also "gut", wenn er die oben genannten Vorteile maximal unterstützt - hierführ kann man zwei Eigenschaften des Entwurfs betrachten: |
| * **Kopplung**: Die Eigenchaft "Kopplung" beschreibt die Bindung zwischen den Klassen. **Die Kopplung soll möglichst gering sein**, das erreicht man dadurch, dass die Abhängigkeiten zu anderen Klassen möglichst klein gehalten werden sollten. Schnittstellen zwischen Klassen sollten klar definiert sein, mit bedeutungsvollen Parametern. Anstatt also eine Getter-Methode zu schreiben, die einen Parameter benötigt, der ihr mitteilt, welches Attribut zurückgegeben werden soll, bekommt jedes Attribut einen eigenen Getter mit sprechendem Namen - und ohne Parameter. | * **Kopplung**: Die Eigenchaft "Kopplung" beschreibt die Bindung zwischen den Klassen. **Die Kopplung soll möglichst gering sein**, das erreicht man dadurch, dass die Abhängigkeiten zu anderen Klassen möglichst klein gehalten werden sollten. Schnittstellen zwischen Klassen sollten klar definiert sein, mit bedeutungsvollen Parametern. Anstatt also eine Getter-Methode zu schreiben, die einen Parameter benötigt, der ihr mitteilt, welches Attribut zurückgegeben werden soll, bekommt jedes Attribut einen eigenen Getter mit sprechendem Namen - und ohne Parameter. |
| |
| | ===== Grundregeln für gute Klassenentwürfe ===== |
| |