principles:high_cohesion
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| principles:high_cohesion [2021-09-02 12:37] – old revision restored (2021-05-11 21:54) 65.21.179.175 | principles:high_cohesion [2021-10-18 21:36] (current) – +++ restored +++ christian | ||
|---|---|---|---|
| Line 6: | Line 6: | ||
| ===== Context ===== | ===== Context ===== | ||
| /* fill in contexts here: */ | /* fill in contexts here: */ | ||
| - | * [[contexts: | + | * [[contexts: |
| + | * [[contexts: | ||
| + | * [[contexts: | ||
| Line 18: | Line 20: | ||
| The cohesion of a module is a measure for how well the internal parts of a module (e.g. the methods and attributes of a class) belong together. Having a high cohesion means, that a module should only comprise responsibilities which belong together. | The cohesion of a module is a measure for how well the internal parts of a module (e.g. the methods and attributes of a class) belong together. Having a high cohesion means, that a module should only comprise responsibilities which belong together. | ||
| - | Several kinds of cohesion can be distinguished some of which are strong and some of which are loose. So strong forms of coupling should be preferred: FIXME add explanation of cohesion types | + | Several kinds of cohesion can be distinguished some of which are strong and some of which are loose. So strong forms of coupling should be preferred. |
| ===== Rationale ===== | ===== Rationale ===== | ||
| Line 24: | Line 26: | ||
| - | ===== Strategies | + | |
| + | |||
| + | ===== Caveats | ||
| + | |||
| + | See section [[#contrary principles]]. | ||
| ===== Origin ===== | ===== Origin ===== | ||
| - | /* the *primary* source */ | ||
| + | W. P. Stevens, G. van Niekerk, G. J. Myers, L. L. Constantine: | ||
| ===== Evidence ===== | ===== Evidence ===== | ||
| Line 35: | Line 41: | ||
| / | / | ||
| - | * [[wiki: | + | * [[wiki: |
| - | * [[wiki: | + | * [[wiki: |
| / | / | ||
| Line 47: | Line 53: | ||
| ==== Specializations ==== | ==== Specializations ==== | ||
| - | * [[Information Expert]]: Adhering to information expert means that a module only has responsibilities which belong together. So this increases cohesion. | ||
| * [[Constantine' | * [[Constantine' | ||
| + | * [[Single Responsibility Principle]] (SRP): SRP is a stronger version of HC. | ||
| + | * [[Interface Segregation Principle]] (ISP): ISP is the application of HC to interfaces. | ||
| ==== Contrary Principles ==== | ==== Contrary Principles ==== | ||
| * [[More Is More Complex]] (MIMC): Making a module highly cohesive often results in additional modules. Sometimes it is simpler to assign a minor unrelated responsibility to a module, which lowers the cohesion. | * [[More Is More Complex]] (MIMC): Making a module highly cohesive often results in additional modules. Sometimes it is simpler to assign a minor unrelated responsibility to a module, which lowers the cohesion. | ||
| + | * [[Model Principle]] (MP): Adhering to HC sometimes means to split up a class into several smaller ones which might correspond to the model less well. | ||
| + | * [[Low Coupling]] (LC): A system consisting of one single module has a very low coupling as there are no dependencies on other modules. But such a system also has low cohesion. The other extreme, very many highly cohesive modules, naturally has a higher coupling between the modules. So here a compromise has to be found. | ||
| ==== Complementary Principles ==== | ==== Complementary Principles ==== | ||
| - | * [[Low Coupling]] (LC): A system consisting of one single module has a very low coupling as there are no dependencies on other modules. But such a system also has low cohesion. | + | * [[Tell don't Ask/ |
| * [[Encapsulate the Concept that Varies]] (ECV): Adhering to HC often results in modules to be split up into several more cohesive ones. ECV gives further advice on how to do that. | * [[Encapsulate the Concept that Varies]] (ECV): Adhering to HC often results in modules to be split up into several more cohesive ones. ECV gives further advice on how to do that. | ||
| Line 66: | Line 75: | ||
| - | ===== Example | + | ===== Examples |
| + | The donkey is good. The site is not working | ||
| Line 74: | Line 84: | ||
| / | / | ||
| / | / | ||
| + | |||
| + | ==== Class level cohesion ==== | ||
| + | |||
| + | Robert Cecil Martin (Uncle Bob) describes maximal cohesion at class level as "a class in which each variable is used by each method" | ||
| + | |||
| + | "In general the more variables a method manipulates the more cohesive that method is to its class." | ||
| + | (Clean Code: A Handbook of Agile Software Craftsmanship - Chapter 10) | ||
| ===== Further Reading ===== | ===== Further Reading ===== | ||
| - | * Albert Endres and Dieter Rombach: //A Handbook of Software and Systems Engineering// | + | * Albert Endres and Dieter Rombach: //[[resources: |
| * [[wp> | * [[wp> | ||
| * [[wiki> | * [[wiki> | ||
| + | * {{page> | ||
| + | |||
| + | ===== Discussion ===== | ||
| + | |||
| + | Discuss this wiki article and the principle on the corresponding [[talk: | ||
principles/high_cohesion.1630579023.txt.gz · Last modified: by 65.21.179.175
