Orchestrator
Backend & Runtime / Knowledge library
High Cohesion
Keeps strongly related behavior and data together
Why learn High Cohesion?
It produces modules with clear purpose and localized changes
The problem it solves
It prevents responsibilities from scattering across unrelated components
Where it came from
High Cohesion is a software design principle that keeps strongly related behavior and data together. Its guarantees and tradeoffs depend on the concrete implementation and operating context.
Build your understanding
Work through these exercises in order. Try the task before opening a reference.
- Define High Cohesion and distinguish it from a neighboring concept.
- Choose a realistic task where High Cohesion is appropriate.
- Identify a failure mode caused by misusing High Cohesion.
- Interpret a small design or result involving High Cohesion.
- Explain one tradeoff or limitation of High Cohesion.
Documentation and sources
- Software Engineering at Google (abseil.io)
Connect the ideas
Explore next
Real World Example
Logistics Routing Cohesion
A regional logistics firm managing last-mile delivery fleets.
The business problem
The firm suffers from a 'God Object' anti-pattern where a single RouteManager class handles database persistence, GPS coordinate parsing, and driver notification logic. When the notification API changes, the entire routing engine requires recompilation and redeployment, leading to frequent, unrelated service outages.
How this topic solves it
By applying high cohesion, we decompose the monolithic RouteManager into specialized, single-responsibility modules. We isolate the GPS parsing logic from the notification dispatching logic, ensuring that each module encapsulates only the data and behavior strictly necessary for its specific domain function.
- Identify distinct functional domains within the existing monolithic class.
- Extract GPS coordinate parsing into a dedicated CoordinateProcessor module.
- Move notification dispatching logic into a separate NotificationService module.
- Define narrow interfaces for communication between the new modules to maintain loose coupling.
- Refactor the original RouteManager to act as a thin orchestrator that delegates tasks to these cohesive components.
This diagram shows the transition from a monolithic structure to a cohesive design where the Orchestrator delegates to specialized modules.
GPS Logic
Alerting Logic
Persistence Layer
- RouteManager → delegates parsing → CoordinateProcessor
- RouteManager → delegates alerting → NotificationService
- CoordinateProcessor → reads raw data → Database
- NotificationService → logs status → Database
Expected business outcome
The system becomes more resilient to change, as modifications to the notification logic no longer risk breaking the core routing algorithms, and individual modules become easier to test in isolation.
Limitations and checks
The primary tradeoff is increased architectural complexity, as developers must now manage multiple smaller files and inter-module communication. This can be verified by checking the number of cross-module dependency cycles; if cycles increase, the boundaries are likely poorly defined.