Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 10:47] – [Semantische, klare Aufgabenverteilung auf Methoden] sbel
+++ faecher:informatik:oberstufe:modellierung:warum:start [26.10.2021 10:56] (aktuell) – [Wann ist ein Klassenentwurf "gut"?] sbel
@@ Zeile 18: / Zeile 18: @@
 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. 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.**
+==== Kohäsion ====
-  * **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.
+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. Das **Single-Responsibility-Prinzip** besagt, dass jede Klasse nur genau eine fest definierte Aufgabe zu erfüllen hat. Diese Aufgabe wird durch das Zusammenspiel aller Attribute und Methoden dieser Klasse erfüllt. Das Zusammenspiel der Attribute und Methoden dieser Klasse ist dadurch also sehr eng - es liegt eine starke Kohäsion vor. **Man möchte also eine hohe Kohäsion der Klassen des Modells haben.**
+==== 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.
+Abhängigkeiten bezieht sich damit sowohl auf die Zahl der Assoziationen (Kontrollkopplung) als auch auf die Komplexität der Bindung (Datenkopplung)((Und noch auf ein paar Aspekte mehr...)).
+Schnittstellen zwischen Klassen sollten also klar und mit möglichst wenig bedeutungsvollen Parametern definiert sein. Anstatt eine get-Methode zu schreiben, die unter Umständen mehrere Parameter benötigt, die ihr mitteilen, welche(s) Attribut(e) zurückgegeben werden soll(en), bekommt jedes Attribut einen eigenen Getter mit sprechendem Namen - und ohne Parameter. Die Aufrufende Klasse kann dann ohne weitere Kenntnisse ihre Aufgaben erfüllen.
 ===== Grundregeln für gute Klassenentwürfe =====
@@ Zeile 44: / Zeile 53: @@
 ==== 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.