Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 15:43] – [Wann ist ein Klassenentwurf "gut"?] sbel
+++ faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 16:22] – [Semantische, klare Aufgabenverteilung in Methoden] sbel
@@ Zeile 6: / Zeile 6: @@
   - Wenn die OO-Modellierung eine Problems nicht eindeutig ist - **woran erkennt man dann, ob man es "gut" gemacht hat?**
-==== 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:
@@ 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 "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:
@@ Zeile 21: / Zeile 21: @@
   * **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 =====
+{{ :faecher:informatik:oberstufe:modellierung:warum:principles.drawio.png |}}
+==== 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 Klassen-Zuständigkeiten ====
+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, ebensowenig wie das Spielfeld: Die Koordinaten gehören logisch zu den Münzen, darum werden sie auch von den Münz-Objekten selbst verwaltet.
+==== Semantische, klare Aufgabenverteilung auf Methoden ====
+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 - "muenzeEinwerfen" und "muenzeSchnippsen", die beiden Methoden sind funktional sehr ähnlich, es macht jedoch Sinn, die beiden zu trennen, da sie logisch zwei Abläufe des Modells umsetzen.