Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.
Beide Seiten, vorherige Überarbeitung Vorherige Überarbeitung Nächste Überarbeitung | Vorherige ÜberarbeitungLetzte ÜberarbeitungBeide Seiten, nächste Überarbeitung | ||
faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 15:33] – sbel | faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 10:50] – [Wann ist ein Klassenentwurf "gut"?] sbel | ||
---|---|---|---|
Zeile 10: | Zeile 10: | ||
Wenn man ein Problem sinnvoll modularisiert und modelliert, hat das viele Vorteile: | Wenn man ein Problem sinnvoll modularisiert und modelliert, hat das viele Vorteile: | ||
- | * Lesbarkeit des Quellcodes -> Etwas stimmt mit dem Tor nicht? Also muss man in der " | + | |
- | * Wenn man Klassen geschickt modelliert, kann man Sie in anderen Programmen wiederverwenden - nicht umsonst spricht man von " | + | * Wenn man **Klassen** geschickt modelliert, kann man Sie in anderen Programmen |
- | * 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 " | ||
+ | |||
+ | Ein Klassenentwurf ist also " | ||
+ | |||
+ | * **Kohäsion**: | ||
+ | Das **Single-Responsibility-Prinzip** besagt, dass jede Klasse nur genau eine fest definierte Aufgabe zu erfüllen hat. Diese Aufgabe wird durch das Zusammenspiel aller Attribute und Methoden dieser Klasse erfüllt. Das Zusammenspiel der Attribute und Methoden dieser Klasse ist dadurch also sehr eng - es liegt eine starke Kohäsion vor. \\ \\Beispiel: Wenn man bei der Implementation einer Liste eine Methode'' | ||
+ | * **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 '' | ||
+ | ==== Klar abgegrenzte Klassen-Zuständigkeiten ==== | ||
+ | |||
+ | **Entlang Zuständigkeiten** zu **modellieren** bedeutet, dass eine **Klasse** einen logisch sinnvollen und klar abgegrenzten Aufgabenbereich besitzt. Im Münz-Schnipsspiel nimmt das Tor zwar Münzen auf, verwaltet aber nicht deren Koordinaten, | ||
+ | |||
+ | ==== Semantische, | ||
+ | |||
+ | Dasselbe, was für die Aufteilung des Problems in Klassen gilt, gilt innerhalb der Klassen für die Methoden: Jede Methode sollte eine klare Aufgabe haben - und einen Namen, der diese Aufgabe auch verdeutlicht. | ||
+ | |||
+ | Die Klasse Spieler hat zwei Methoden - '' | ||
+ | |||
+ | ==== Keine Redundanz (DRY-Prinzip) ==== | ||
+ | |||
+ | Man sollte es tunlichst vermeiden, identischen, | ||
+ | |||
+ | In unserem Beispiel gibt es eine Methode '' | ||