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 16:14] – [Grundregeln für gute Klassenentwürfe] sbel | faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 09:05] – [Grundregeln für gute Klassenentwürfe] Mareike Nutz | ||
---|---|---|---|
Zeile 22: | Zeile 22: | ||
===== Grundregeln für gute Klassenentwürfe ===== | ===== Grundregeln für gute Klassenentwürfe ===== | ||
+ | {{ : | ||
- | {{ : | ||
==== Kapselung und Geheimnisprinzip ==== | ==== Kapselung und Geheimnisprinzip ==== | ||
- | Klassenvariablen niemals öffentlich (public) deklarieren. | + | 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**. | 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. | 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 ==== | + | ==== Klar abgegrenzte |
+ | |||
+ | Entlang Zuständigkeiten zu modellieren bedeutet, dass eine Klasse einen logisch sinnvollen und klar abgegrenzten Aufgabenbereich besitzt. Im Münz-Schnipssspiel 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 die 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 '' | ||