Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige Überarbeitung Nächste ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 15:39] – [Wann ist ein Klassenentwurf "gut"?] sbel | faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 16:14] – [Kapselung und Geheimnisprinzip] sbel | ||
---|---|---|---|
Zeile 6: | Zeile 6: | ||
- Wenn die OO-Modellierung eine Problems nicht eindeutig ist - **woran erkennt man dann, ob man es " | - Wenn die OO-Modellierung eine Problems nicht eindeutig ist - **woran erkennt man dann, ob man es " | ||
- | ==== Warum verteilt man die Funktionalität und den Code auf mehrere Klassen? ==== | + | ===== Warum verteilt man die Funktionalität und den Code auf mehrere Klassen? |
Wenn man ein Problem sinnvoll modularisiert und modelliert, hat das viele Vorteile: | Wenn man ein Problem sinnvoll modularisiert und modelliert, hat das viele Vorteile: | ||
Zeile 14: | Zeile 14: | ||
* **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 " | * **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 " | ||
- | ==== Wann ist ein Klassenentwurf " | + | ===== Wann ist ein Klassenentwurf " |
Ein Klassenentwurf ist also " | Ein Klassenentwurf ist also " | ||
- | * **Kohäsion**: | + | * **Kohäsion**: |
+ | * **Kopplung**: | ||
+ | ===== Grundregeln für gute Klassenentwürfe ===== | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== Kapselung und Geheimnisprinzip ==== | ||
+ | |||
+ | Klassenvariablen niemals öffentlich (public) deklarieren. Zugriff auf Attribute von anderen nur über sondierende und verändernde Methoden (get- und set-Methoden) möglich. Änderungen am internen Aufbau der Klasse haben keine Auswirkungen auf andere Klassen, welche mit dieser assoziiert sind. | ||
+ | |||
+ | Die Verwaltung der Position der Münzen in unserem Beispiel ist in Verantwortung der Muenzen-Klasse. Sollte die Verwaltung intern später auf ein Array mit zwei Feldern für x- und y-Koordinate umgestellt werden, so müssten bei direktem Zugriff von außen alle zugreifenden Klassen mitverändert werden - wenn der Zugriff über Getter- und Setter-Methoden gekapselt ist, müssen die assoziierten Klassen nichts über den internen Aufbau der Muenzen-Klasse wissen. Man spricht vom **Geheimnisprinzip**. | ||
+ | Anhand von Zuständigkeiten modellieren heißt, dass eine Klasse einen logisch sinnvollen und klar abgegrenzten Aufgabenbereich besitzt. Im Murmelspiel nimmt das Loch lediglich Murmeln auf, verwaltet aber nicht deren Koordinaten. | ||
+ | |||
+ | ==== Klar abgegrenzte Zuständigkeiten ==== | ||