Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:modellierung:warum:start [25.10.2021 16:21] – [Klar abgegrenzte Zuständigkeiten] sbel
+++ faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 09:33] – [Warum verteilt man die Funktionalität und den Code auf mehrere Klassen?] Mareike Nutz
@@ Zeile 10: / Zeile 10: @@
 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 "tor"-Klasse schauen und nicht 5000Zeilen Code durchscrollen, bis man zu dem Teil kommt, der das Tor erzeugt. Es **erleichtert Änderungen** an der Funktionalität, wenn stets klar ist, wo bestimmte Eigenschaften und Fähigkeiten festgelegt sind.
+  * **Lesbarkeit des Quellcodes** -> Etwas stimmt mit dem Tor nicht? Also muss man in der "tor"-Klasse schauen und nicht 5000 Zeilen Code durchscrollen, bis man zu dem Teil kommt, der das Tor erzeugt. Es **erleichtert Änderungen** an der Funktionalität, wenn stets klar ist, wo bestimmte Eigenschaften und Fähigkeiten festgelegt sind.
   * Wenn man **Klassen** geschickt modelliert, kann man Sie in anderen Programmen **wiederverwenden** - nicht umsonst spricht man von "Klassenbibliotheken".
   * **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.
@@ Zeile 23: / Zeile 23: @@
 ===== Grundregeln für gute Klassenentwürfe =====
-{{ :faecher:informatik:oberstufe:modellierung:warum:principles.drawio.png |}}
+{{ :faecher:informatik:oberstufe:modellierung:warum:principles2.drawio.png |}}
 ==== Kapselung und Geheimnisprinzip ====
@@ Zeile 32: / Zeile 34: @@
 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 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 in Methoden ====
+==== 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.
+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.
+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.
-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.