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)

  1. Functional cohesion — The ideal; all elements contribute to a single, well-defined task
  2. Sequential cohesion — Elements form a processing pipeline; one element’s output feeds the next
  3. Communicational cohesion — Groups elements that operate on the same data
  4. Procedural cohesion — Elements execute in sequence but serve different purposes
  5. Temporal cohesion — Elements execute at the same time but are otherwise unrelated
  6. Logical cohesion — Elements perform similar types of operations but on different data
  7. 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.

  • 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.

  • 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 →