Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 10:46] – [Klar abgegrenzte Klassen-Zuständigkeiten] sbel
+++ faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 10:47] – [Semantische, klare Aufgabenverteilung auf Methoden] sbel
@@ Zeile 32: / Zeile 32: @@
 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. In unserem Münzspiel überprüft das Tor zwar, ob eine Münze getroffen hat, verwaltet aber nicht die Koordinaten der Münzen.
 ==== Klar abgegrenzte Klassen-Zuständigkeiten ====
@@ Zeile 41: / Zeile 38: @@
 ==== Semantische, klare Aufgabenverteilung auf Methoden ====
-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.
+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 - "muenzeEinwerfen" und "muenzeSchnipsen", die beiden Methoden sind funktional sehr ähnlich, es macht jedoch Sinn, die beiden zu trennen, da sie logisch zwei Abläufe des Modells umsetzen.
+Die Klasse Spieler hat zwei Methoden - ''muenzeEinwerfen'' und ''muenzeSchnipsen'', die beiden Methoden sind funktional sehr ähnlich, es macht jedoch Sinn, die beiden zu trennen, da sie logisch zwei Abläufe des Modells umsetzen.
 ==== Keine Redundanz (DRY-Prinzip) ====