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:48] – [Keine Redundanz (DRY-Prinzip)] 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) ====
-Man sollte es tunlichst vermeiden, identischen, also redundanten, Code an mehreren Stellen eines Programms zu verwenden. Dieses Prinzip wird oft auch das DRY-Prinzip (//Don't repeat youself//) genannt. So spart man Schreibaufwand, das Programm ist leichter zu verstehen und zu warten, denn man muss den Code nur einmal ändern und nicht noch alle Redundanzen.
+Man sollte es tunlichst vermeiden, identischen, also redundanten, Code an mehreren Stellen eines Programms zu verwenden. Dieses Prinzip wird oft auch das **DRY-Prinzip** (//Don't repeat youself//) genannt. So spart man Schreibaufwand, das Programm ist leichter zu verstehen und zu warten, denn man muss den Code nur einmal ändern und nicht noch alle Redundanzen.
 In unserem Beispiel gibt es eine Methode ''setPosition()'' des Münz-Objekts, diese wird von allen assoziierenden Klassen aufgerufen, wenn die Position der Münze verändert werden soll. Wäre es an mehreren Stellen des Programmcodes möglich die entsprechenden Attribute des Münz-Objekts zu beeinflussen, müssten bei einer internen Änderung alle diese Stellen angepasst werden.