|
| 1 | += Kohäsionskriterien |
| 2 | +:categories: design-principles |
| 3 | +:roles: software-architect, software-developer, consultant, educator |
| 4 | +:related: grasp, solid-srp, clean-architecture, vertical-slice-architecture |
| 5 | +:proponents: Larry Constantine, Edward Yourdon |
| 6 | +:tags: cohesion, coupling, module design, structured design, code quality |
| 7 | +:tier: 2 |
| 8 | + |
| 9 | +[%collapsible] |
| 10 | +==== |
| 11 | +Vollständiger Name:: Kohäsionskriterien (Constantine & Yourdon) |
| 12 | + |
| 13 | +Auch bekannt als:: Kohäsionsstufen, Kohäsionsskala, Modulkohäsionstypen |
| 14 | + |
| 15 | +[discrete] |
| 16 | +== *Kernkonzepte*: |
| 17 | + |
| 18 | +Sieben Stufen der Kohäsion, geordnet von schlecht (1) bis ideal (7): |
| 19 | + |
| 20 | +Zufällige Kohäsion (1):: Elemente sind willkürlich gruppiert, ohne sinnvollen Zusammenhang. Typisches Zeichen: Utility-Klassen oder Sammelmodule. |
| 21 | + |
| 22 | +Logische Kohäsion (2):: Elemente führen ähnliche Aktivitäten aus, die über ein Steuerflag ausgewählt werden. Beispiel: eine Funktion für alle I/O-Operationen (lesen, schreiben, drucken), gesteuert durch einen Parameter. |
| 23 | + |
| 24 | +Temporale Kohäsion (3):: Elemente sind gruppiert, weil sie zur gleichen Zeit ausgeführt werden. Beispiel: Initialisierungsroutinen beim Programmstart. |
| 25 | + |
| 26 | +Prozedurale Kohäsion (4):: Elemente sind gruppiert, weil sie einer bestimmten Ausführungsreihenfolge folgen. Beispiel: eine Funktion, die Eingaben validiert, dann eine Datei öffnet, dann ein Log schreibt. |
| 27 | + |
| 28 | +Kommunikative Kohäsion (5):: Elemente arbeiten auf denselben Daten, führen aber unterschiedliche Operationen aus. Beispiel: ein Modul, das einen Kundendatensatz sowohl validiert als auch formatiert. |
| 29 | + |
| 30 | +Sequentielle Kohäsion (6):: Die Ausgabe eines Elements dient als Eingabe des nächsten, eine Pipeline bildend. Beispiel: parsen -> validieren -> transformieren. |
| 31 | + |
| 32 | +Funktionale Kohäsion (7):: Jedes Element trägt zu genau einer wohldefinierten Aufgabe bei. Das Ideal. Beispiel: `berechneVersandkosten()` tut genau eine Sache. |
| 33 | + |
| 34 | + |
| 35 | +Hauptvertreter:: Larry Constantine und Edward Yourdon ("Structured Design", 1979). Weiterentwickelt von Meilir Page-Jones ("The Practical Guide to Structured Systems Design", 1988). |
| 36 | + |
| 37 | +[discrete] |
| 38 | +== *Wann verwenden*: |
| 39 | + |
| 40 | +* Bewertung der Modulqualität bei Code Reviews oder Refactoring |
| 41 | +* Entscheidung, ob eine Klasse oder ein Modul aufgeteilt werden sollte |
| 42 | +* Argumentation für Refactoring mit konkreten Kriterien statt Bauchgefühl |
| 43 | +* Lehre im Softwaredesign: die Skala macht abstrakte Qualität greifbar |
| 44 | +* Bewertung von Architekturentscheidungen zu Modulgrenzen |
| 45 | + |
| 46 | +[discrete] |
| 47 | +== *Verwandte Anker*: |
| 48 | + |
| 49 | +* <<grasp,GRASP>> - "High Cohesion" ist eines der neun GRASP-Patterns |
| 50 | +* <<solid-srp,SOLID SRP>> - Single Responsibility Principle zielt auf funktionale Kohäsion |
| 51 | +* <<clean-architecture,Clean Architecture>> - Organisiert Code nach kohäsiven Geschäftsregeln |
| 52 | +* <<vertical-slice-architecture,Vertical Slice Architecture>> - Gruppiert nach Feature-Kohäsion statt technischer Schicht |
| 53 | +==== |
0 commit comments