Differences

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

--- principles:high_cohesion [2012-12-18 10:03] – external edit 127.0.0.1
+++ principles:high_cohesion [2021-10-18 21:36] (current) – +++ restored +++ christian
@@ Line 6: / Line 6: @@
 ===== Context =====
 /* fill in contexts here: */
   * [[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.
-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 =====
@@ Line 24: / Line 26: @@
-===== Strategies =====
+===== Caveats =====
+See section [[#contrary principles]].
 ===== Origin =====
-/* the *primary* source */
+W. P. Stevens, G. van Niekerk, G. J. Myers, L. L. Constantine: //Structured design//
 ===== Evidence =====
@@ Line 35: / Line 41: @@
 /*[[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]]*/
@@ Line 47: / Line 53: @@
 ==== Specializations ====
-  * [[principles:Information Expert]]: Adhering to information expert means that a 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.
-  * [[principles:Constantine's Law]]
+  * [[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 ====
-  * [[principles:Keep It Simple Stupid]]: Sometimes it is simpler to assign a minor unrelated responsibility to a module, which lowers the cohesion. On the other hand introducing a new module for the responsibility would be better in terms of cohesion but increases complexity as it increases the number of modules.
+  * [[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 ====
-  * [[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]]).
-  * [[principles: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 ====
@@ Line 65: / Line 75: @@
-===== Example =====
+===== Examples =====
+The donkey is good. The site is not working
@@ Line 73: / Line 84: @@
 /*[[wiki:Incomplete]]*/
 /*[[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 =====
-  * 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)]]
   * [[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]].