Principles Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== High Cohesion (HC) ======

===== Variants and Alternative Names =====


===== Context =====
/* fill in contexts here: */
  * [[contexts:Object-Oriented Design]]
  * [[contexts:API Design]]
  * [[contexts:Architecture]]


===== Principle Statement =====

[[glossary:Cohesion]] in a [[glossary:module]] should be high.


===== Description =====

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
===== Rationale =====

Not adhering to this principle, i.e. having a low cohesion, means that one module has several unrelated or only loosely related responsibilities. A change in the requirements for one of these may thus also affect the others which would not be the case in a highly cohesive module.


===== Strategies =====

  * Divide one large module into several smaller but more cohesive ones
===== Caveats =====

See section [[#contrary principles]].


===== Origin =====


===== Evidence =====
/* Comment out what is not applicable and explain the rest: */
/*[[wiki:Proposed]]*/

  * [[wiki:Examined]]
  * [[wiki:Accepted]] The concept of high cohesion is widely known and described in several well-known books for example in Craig Larman's //Applying UML and Patterns//

/*[[wiki:Questioned]]*/


===== Relations to Other Principles =====

==== Generalizations ====

==== Specializations ====

  * [[Constantine's Law]]: Constantine's Law is just the combination of HC and LC.
  * [[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 ====

  * [[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 ====

  * [[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]]). 
  * [[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 ====

{{page>collections:OOD Principle Language#Box}}
{{page>collections:GRASP#Box}}


===== Examples =====


===== Description Status =====
/* Choose one of the following and comment out the rest: */
[[wiki:Stub]]
/*[[wiki:Incomplete]]*/
/*[[wiki:Complete]]*/

===== Further Reading =====

  * Albert Endres and Dieter Rombach: //A Handbook of Software and Systems Engineering//. p. 43pp.
  * [[wp>Cohesion (computer science)]]
  * [[wiki>CouplingAndCohesion]]
  * Craig Larman: //Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and Iterative Development//