| 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:25] – [Semantische, klare Aufgabenverteilung auf Methoden] sbel | faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 09:40] – [Wann ist ein Klassenentwurf "gut"?] Mareike Nutz |
|---|
| Wenn man ein Problem sinnvoll modularisiert und modelliert, hat das viele Vorteile: | 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". | * 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. | * **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: | Ein Klassenentwurf ist also "gut", wenn er die oben genannten Vorteile maximal unterstützt - hierfür kann man zwei Eigenschaften des Entwurfs betrachten: |
| |
| * **Kohäsion**: Die Kohäsion einer Klasse definiert ihren logischen Zusammenhalt als Einheit. Erennen kann man das daran, wie deutlich Sie sich von anderen Klassen des Modells abgrenzt, aber auch daran, dass ihre Methoden für klar umrissene Aufgaben zuständig sind. Beispiel: Wenn man bei der Implementation einer Liste eine Methode''isEmpty(): boolean'' definiert, die nur schaut, ob der Startknoten null ist, erscheint das im ersten Augenblick übertrieben, erhöht jedoch die Kohäsion der Klasse. Antatt an vielen Stellen eine interpretationsbedürftige Abfrage ''start==null'' im Code zu haben, hat man eine semantisch klare Methode ''isEmpty()''. **Man möchte also eine hohe Kohäsion der Klassen haben.** | * **Kohäsion**: Die Kohäsion einer Klasse definiert ihren logischen Zusammenhalt als Einheit. Erkennen kann man das daran, wie deutlich Sie sich von anderen Klassen des Modells abgrenzt, aber auch daran, dass ihre Methoden für klar umrissene Aufgaben zuständig sind. Beispiel: Wenn man bei der Implementation einer Liste eine Methode''isEmpty(): boolean'' definiert, die nur schaut, ob der Startknoten null ist, erscheint das im ersten Augenblick übertrieben, erhöht jedoch die Kohäsion der Klasse. Anstatt an vielen Stellen eine interpretationsbedürftige Abfrage ''start==null'' im Code zu haben, hat man eine semantisch klare Methode ''isEmpty()''. **Man möchte also eine hohe Kohäsion der Klassen haben.** |
| * **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. | * **Kopplung**: Die Eigenschaft "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 ===== | ===== 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 ==== | ==== Kapselung und Geheimnisprinzip ==== |
| ==== Semantische, klare Aufgabenverteilung auf Methoden ==== | ==== 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. | 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. |
| |
| 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. | ==== Keine Redundanz (DRY-Prinzip) ==== |
| |
| ==== Kein doppelter Code ==== | 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 Code an mehreren Stellen eines Programms pflegen zu müssen. Es gibt 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. | 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. |
| |
| |