Manu's Vault

Cohesion (Component Modeling)

3 min readStatus:Seedling

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 content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks