Niedrige Kohäsion und hohe Kopplung

[Robert R.]

Hallo,

laut meinem Prof gilt:
"Niedrige Kohäsion geht oft Hand in Hand mit hoher Kopplung."

das versteh ich jetzt nicht ganz. Niedrige Kohäsion = eine Klasse übernimmt viele Aufgaben. Hohe Kopplung = Klassen sind viel von anderen Klassen abhängig.

So, wenn jetzt eine Klasse quasi viele Klassen in sich vereinigt, viele Aufgaben übernimmt. Dann hat man doch eine niedrige Kopplung. Deswegen kann ich die Aussage von meinem Prof nicht nachvollziehen.

Viele Grüße

[LX]

Kopplung könnte in diesem Kontext auch passiv gemeint sein, d.h. wenn die Klasse viele Aufgaben wahrnimmt, wird sie mit hoher Wahrscheinlichkeit von vielen anderen Klassen einbezogen.

Nur so eine Vermutung.

Gruß, Alex

[Texter mit x]

Prof fragen, die wenigsten beißen.

[Der Martin]

Hi,

laut meinem Prof gilt:
"Niedrige Kohäsion geht oft Hand in Hand mit hoher Kopplung."

dazu ein Beispiel:
Wasser hat eine sehr niedrige Kohäsion[*].
Aber Wasser überträgt sowohl Wärme, als auch elektrische Ladung, als auch mechanische Schwingungen (Schall) recht gut.

Nur was das mit "PROGRAMMIERTECHNIK" zu tun haben mag, entzieht sich meinem Verständnis.

So long,
 Martin

[*] Kohäsion: Der Zusammenhalt der Moleküle eines Stoffs untereinander.

[Juve]

Glück auf!

Nur was das mit "PROGRAMMIERTECHNIK" zu tun haben mag, entzieht sich meinem Verständnis.

Die Antwort liegt nicht allzuweit da draußen: Kohäsion (Informatik). Wie es der Artikel ja auch ausdrückt, ist hohe Kohäsion eine Qualitätskriterium (nicht nur) für OO-Software. Im Software Engineering gibt es das Prinzip des Divide&Conquer, das, vereinfacht gesagt, eine einfache Beherrschbarkeit des System durch geschicktes Zerlegen/Teilen zu erreichen sucht.
Sorry, mehr fällt mir jetzt aus dem Stand auch nicht mehr ein, aber vielleicht sind ja ein paar brauchbare Stichworte zum weiterrecherchieren dabei.

Gruß,
der Juve

[Daniel Thoma]

Hallo Juve,

Im Software Engineering gibt es das Prinzip des Divide & Conquer

"Devide and Conquer" ist alledings ein Prinzip zum Entwurf von Algorithmen (Klassisches Beispiel: Quicksort). Dabei zerlegt man ein Problem rekursiv in _gleichartige_ Teilprobleme und setzt die Ergebnisse wieder zusammen.

Kohäsion und Kopplung (Cohesion, Coupling) beziehen sich dagegen auf die Zerlegung eines Systems in funktionale _verschiedene_ Teile.

Grüße

Daniel

[Juve]

Glück auf!

Hallo Juve,

Im Software Engineering gibt es das Prinzip des Divide & Conquer
"Devide and Conquer" ist alledings ein Prinzip zum Entwurf von Algorithmen (Klassisches Beispiel: Quicksort). Dabei zerlegt man ein Problem rekursiv in _gleichartige_ Teilprobleme und setzt die Ergebnisse wieder zusammen.

Nicht nur. Zumindest wurde mir Divide&Conquer auch im Rahmen des SE, also der Entwicklung entsprechend großer, komplexer Softwaresysteme, beigebracht. Dabei zerlegt man das System iterativ in immer kleinere Einheiten (Units), die jeweils für eine in sich abgeschlossene Aufgabe zuständig sein bzw. in der OO-Modellierung Klassen, die jeweils genau eine abgeschlossene Einheit repräsentieren.
Diese Units werden dann nachher wieder zum System zusammengesetzt (integriert), deswegen bspw. auch die Unterteilung in Unit- und Integration-Tests. Aber erstens schweife ich ab, zweitens fehlt mir für eine detaillierte Betrachtung im Moment die Zeit und das passende Nachschlagewerk ;)

Gruß,
der Juve

[Daniel Thoma]

Hallo Juve,

Hm, man könnte wohl die Vorgehensweise als Anwendung des Devide and Conquer-Prinzips betrachten, indem man eben zerlegen und integrieren als die beiden Schritte auffasst. Dann tut man wieder auf jeder Ebene das gleiche, nämlich das jeweilige Subsystem analysieren. Vielleicht war das so gemeint.

Grüße

Daniel

[Daniel Thoma]

Hallo Robert,

Kohäsion ist die Zusammengehörigkeit der Aufgaben, die eine Klasse realisiert.
Kopplung sind die Beziehungen einer Klasse zu anderen.

Wenn man nun niedrige Kohäsion hat, macht die Klasse viele Dinge, die eigentlich nicht zusammengehören. Um viele verschiedene Dinge zu tun, benötigt man viele verschiedene Werkzeuge. Daher benötigt man entsprechend mehr andere Klassen womit man die hohe Kopplung hat.

Man könnte das auch übersetzen als: Wenn man es nicht schafft, sein Programm in funktional zusammengehörige Einheiten zu zerlegen, produziert man ein undurchschaubares Chaos ;-)
Es macht durchaus Sinn, dieses Prinzip mal zu realisieren und ab und an zu überlegen, ob man es gerade auch berücksichtigt. Allerdings wird es in Softwareengineeringvorlesungen gerne etwas breiter getreten als nötig, weil den Leuten nicht viel mehr zu Softwarearchitektur einfällt ;-)

Grüße

Daniel