User Tools

Site Tools


principles:high_cohesion

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
principles:high_cohesion [2013-02-06 13:54] – [Contrary Principles] -KISS; see MIMC christianprinciples: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:Object-Oriented Design]] +  * [[contexts:Object-Oriented Design]] 
 +  * [[contexts:API Design]] 
 +  * [[contexts:Architecture]]
  
  
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: //Structured design//
  
 ===== Evidence ===== ===== Evidence =====
Line 35: Line 41:
 /*[[wiki:Proposed]]*/ /*[[wiki:Proposed]]*/
  
-  * [[wiki:Examined]] +  * [[wiki:Examined]]: There are metrics that try to measure cohesion and there are studies relating these cohesion measures to the number of errors found during testing (({{page>resources:A Handbook Of Software And Systems Engineering#reference}})). This correlation is evident. The limitation of these studies is that these cohesion metrics cannot represent the cohesion notion completely. 
-  * [[wiki:Accepted]]+  * [[wiki:Accepted]] The concept of high cohesion is widely known and described in several well-known books for example in {{page>resources:Applying UML And Patterns#reference}}.
  
 /*[[wiki:Questioned]]*/ /*[[wiki:Questioned]]*/
Line 47: Line 53:
 ==== Specializations ==== ==== Specializations ====
  
-  * [[Information Expert]]: Adhering to information expert means that module only has responsibilities which belong together. So this increases cohesion+  * [[Constantine's Law]]: Constantine's Law is just the combination of HC and LC. 
-  * [[Constantine's Law]]+  * [[Single Responsibility Principle]] (SRP): SRP is 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]] +  * [[Tell don't Ask/Information Expert]] (TdA/IE): IE may help finding solutions with high cohesion. On the other hand it may also be disadvantageous in some cases (see [[Tell don't Ask/Information Expert#caveats]]).  
-  * [[Principle of Least Surprise]]+  * [[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.
  
 ==== Principle Collections ==== ==== Principle Collections ====
Line 66: Line 75:
  
  
-===== Example =====+===== Examples ===== 
 +The donkey is good. The site is not working
  
  
Line 74: Line 84:
 /*[[wiki:Incomplete]]*/ /*[[wiki:Incomplete]]*/
 /*[[wiki:Complete]]*/ /*[[wiki:Complete]]*/
 +
 +==== 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//. p. 43pp.+  * Albert Endres and Dieter Rombach: //[[resources:A Handbook of Software and Systems Engineering]]//. p. 43pp.
   * [[wp>Cohesion (computer science)]]   * [[wp>Cohesion (computer science)]]
   * [[wiki>CouplingAndCohesion]]   * [[wiki>CouplingAndCohesion]]
 +  * {{page>resources:Applying UML And Patterns#reference}}
 +
 +===== Discussion =====
 +
 +Discuss this wiki article and the principle on the corresponding [[talk:principles:High Cohesion|talk page]].
  
principles/high_cohesion.1360155294.txt.gz · Last modified: 2013-05-19 22:10 (external edit)