High Cohesion / Loose Coupling

Design PrinciplesMid

The Question

What is high cohesion and loose coupling and why do they matter?

What a Strong Answer Covers

• Both terms defined distinctly.

Senior-Level Answer

**Cohesion** measures how strongly related the responsibilities inside a single module or class are. High cohesion means everything in the unit works toward one clear purpose. A class that handles user authentication and also formats PDF reports has low cohesion — its responsibilities are unrelated. High cohesion makes units easier to understand, test, and reuse because there is a single axis of change.

**Coupling** measures how much one module depends on the internal details of another. Tight coupling means a change in module A forces changes in module B. Loose coupling means modules interact only through stable, narrow interfaces — they know what the other module does, not how it does it.

The two principles are complementary: high cohesion pushes related behavior together, loose coupling pushes unrelated modules apart. Together they minimize the blast radius of change.

**Practical forms of coupling to reduce:** - **Data coupling**: pass only the data a function needs, not entire objects - **Control coupling**: don't pass flags that change internal behavior — split into two functions - **Content coupling**: never access another module's private state directly - **Common coupling**: avoid shared global mutable state

**Techniques for loose coupling:** - Depend on interfaces/abstract classes rather than concrete implementations (Dependency Inversion) - Inject dependencies rather than instantiating them internally - Use events or message queues to decouple producers from consumers - Define clear module boundaries with versioned contracts (APIs)

In a microservices context, a service with high cohesion owns one business domain end-to-end. Loose coupling means services communicate over APIs, not shared databases. A change to the Order service's database schema should not require the Inventory service to be redeployed.

The interview signal: candidates who can cite a real refactoring — 'we extracted a notification module because it was tangled with billing' — demonstrate they have lived the tradeoff, not just memorized the definition.

What Separates a 2/3 from a 3/3

Common Mistakes

• Confusing the two — saying 'coupling means things work together' (that's cohesion)
• Treating loose coupling as always better — very loose coupling (microservices everywhere) has coordination costs
• Describing coupling only at the class level, missing the microservice/system level
• Not mentioning dependency injection as the main implementation technique

Follow-Up Questions

• How does dependency injection reduce coupling? — The caller provides dependencies rather than the callee creating them — the callee only knows the interface, not the concrete type.
• What is the difference between high cohesion and the Single Responsibility Principle? — SRP is one axis of change; cohesion is about relatedness of internal elements — SRP is a stricter, change-oriented framing.
• Give an example of a change that would be easy in a well-designed system but hard in a tightly coupled one. — Swapping a payment provider — loose coupling means only the payment adapter changes; tight coupling ripples through the checkout flow.
• How do you recognize low cohesion in a code review? — Long classes, methods that take many unrelated parameters, classes with names like 'Manager' or 'Utils' that grow unbounded.

Related Questions

• Singleton
• Factory
• Strategy
• Observer
• IoC / Dependency Injection