Cohesion
The cohesion series reworks one of the oldest concepts in software design. Its core conclusions are developed across this set of pages.
- Cohesion: core conclusions — cohesion is correctness relative to a partitioning rule; the (purity, completeness) pair and the cohesion profile; why structural proxies do not define cohesion; the Γ-equivalence rule and causal cohesion; the four necessary conditions.
- Cohesion and knowledge embodiment — the knowledge-embodiment theorem: maximal cohesion is maximal embodiment of domain knowledge.
- Why cohesion has no scalar metric — four proved failure modes of any single-number cohesion score: it cannot see the rule, collapses two opposite defects, cannot name the repair target, and degenerates into the rule when it does decide.
- Why two metrics are necessary — the two-axis proof: one axis cannot separate impurity from incompleteness, two axes can, and the pair is the minimal adequate output per rule.
1 Where cohesion sits
Cohesion and coupling are the two classical “quality” measures of modular structure. The cohesion series gives cohesion a principled definition: correctness relative to a partitioning rule [1]. The coupling page does the same for coupling — and shows that within any single dimension, coupling is a consequence of cohesion, not an independent objective.
Cohesion is distinct from IVP, though the two are related. IVP groups elements by change-driver assignment. Cohesion is the more general measure of correctness relative to any partitioning rule. The change-driver rule is one instance of that general idea — the instance IVP is built on.
The formal development. The definitions, theorems, and proofs behind this page are published in:
- On the Nature of Cohesion: Cohesion as Correctness Relative to a Partitioning Rule — Zenodo, 2026 — doi:10.5281/zenodo.21703193