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 16:22] – [Klar abgegrenzte Zuständigkeiten] 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 " | + | * **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 **wiederverwenden** - nicht umsonst spricht man von " | ||
* **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 " | ||
Zeile 16: | Zeile 16: | ||
===== Wann ist ein Klassenentwurf " | ===== Wann ist ein Klassenentwurf " | ||
- | Ein Klassenentwurf ist also " | + | Ein Klassenentwurf ist also " |
- | * **Kohäsion**: | + | * **Kohäsion**: |
- | * **Kopplung**: | + | 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 ===== | ===== 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**. | + | ==== Kapselung |
- | 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. | + | |
+ | **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 ==== | ==== 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-Schnipssspiel | + | **Entlang Zuständigkeiten** zu **modellieren** bedeutet, dass eine **Klasse** einen logisch sinnvollen und klar abgegrenzten Aufgabenbereich besitzt. Im Münz-Schnipsspiel |
+ | |||
+ | ==== 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, | ||
- | ==== Semantische, klare Aufgabenverteilung in Methoden ==== | + | In unserem Beispiel gibt es eine Methode '' |
- | Dasselbe, was für die Aufteilung des Probnlems in Klassen gilt, gilt innerhalb der Klassen für die Methoden: Jede Methode sollte eine klare Aufgabe haben - und einen Namen, der die Aufgabe auch verdeutlicht. | ||
- | Die Klasse Spieler hat zwei Methoden - " |