Core Idea
Cohesion measures how well the elements within a module belong together. High cohesion means module elements are strongly related and work toward a unified purpose; low cohesion indicates loosely related or unrelated elements grouped arbitrarily.
Definition
Cohesion is a qualitative measure of how focused and unified a module’s internal elements are. High cohesion means a module’s classes, functions, and data work together to achieve a single, well-defined purpose. Low cohesion means elements don’t naturally belong together—grouped by convenience, historical accident, or organizational structure rather than logical necessity.
The concept emerged from structured programming research and asks a deceptively simple question: “Do these things actually belong together?”
Levels of Cohesion (strongest to weakest)
- Functional cohesion — The ideal; all elements contribute to a single, well-defined task
- Sequential cohesion — Elements form a processing pipeline; one element’s output feeds the next
- Communicational cohesion — Groups elements that operate on the same data
- Procedural cohesion — Elements execute in sequence but serve different purposes
- Temporal cohesion — Elements execute at the same time but are otherwise unrelated
- Logical cohesion — Elements perform similar types of operations but on different data
- Coincidental cohesion — No meaningful relationship between elements at all
Why It Matters
- Code comprehension: High cohesion reduces cognitive load—developers encounter a focused set of related concerns rather than scattered functionality; they can understand a module without holding the entire system in mind
- Maintainability: Changes localize within single modules; low cohesion scatters related functionality across multiple modules, turning simple changes into archaeological expeditions
- Testing: Highly cohesive modules are easier to test in isolation—fewer test cases achieve coverage, exercising logically related functionality
- Microservices scope: Service cohesion determines whether services have clear boundaries; poor cohesion forces teams to coordinate across service boundaries even for logically related changes
Architectural ideal: High cohesion within modules and low Coupling between them—modules that are internally focused yet externally independent. This combination maximizes maintainability, testability, and ability to reason about system behavior.
Related Concepts
- Modularity — The organizing principle that cohesion helps measure
- Coupling — The complementary metric measuring dependencies between modules
- Connascence — A more sophisticated framework for understanding module relationships
- Component-Definition — Architectural units where cohesion principles apply
- Separation of Concerns — The design principle that high cohesion enables
- Single Responsibility Principle — Object-oriented principle aligned with high cohesion
- Fundamentals of Software Architecture - Richards & Ford - 2020 — Source literature
Sources
-
Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 3: Modularity, pp. 39-54
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
-
Yourdon, Edward and Larry L. Constantine (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall. ISBN: 978-0138544713.
- Original formalization of cohesion types and measurement
Note
This note was researched and drafted with AI. How these notes are written →