Cohesion and Coupling — The Two Forces That Decide Whether Code Is Editable
Fast recall
Quick revision
Core answer
Whether you understand that cohesion and coupling are the underlying physics of maintainability — the reason SOLID, layers, and design patterns all exist. This is a design-judgment question, not a definition-recall question. Interviewers ask it to see if you can reason about why a refactor helps, not just how to do it.
Defining the terms but not explaining the tradeoff or the failure mode. Saying 'high cohesion good, low coupling good' without showing what high coupling or low cohesion actually breaks. A second mistake: confusing the two — coupling is between modules, cohesion is within a module.
Frame both as spectrum, not binary. Give the concrete failure: high coupling means a one-line change ripples to 10 files; low cohesion means a bug fix requires understanding a 2000-line class. Mention that Spring's layered architecture (controller → service → repository) is literally a high-cohesion-low-coupling structure, and that interfaces are the primary coupling-reduction tool.
Interview-ready guide
Interview answer
Cohesion and coupling are the two forces that decide whether code stays editable as it grows. Cohesion is a property of a single module — how focused it is on one responsibility. Coupling is a property of the relationship between modules — how much one knows about the other.
High cohesion means each class does one thing well — an EmailSender class is cohesive, every method is about sending email. Low cohesion is the god class that does user creation, email, invoicing, and document archiving in one 2000-line file, where every bug fix risks the whole thing and nobody can say what the class is for. The fix is splitting by responsibility — that's the Single Responsibility Principle.
Low coupling means modules talk through narrow, stable interfaces. The worst is content coupling — reaching into private fields. The best is message coupling — depending on a one-method interface. The classic high-coupling smell is a service that knows its repository's concrete internals, so changing the database breaks the service. The fix is depending on an interface and injecting it — that's the Dependency Inversion Principle, and it's exactly what Spring's constructor injection does.
The goal is both high cohesion and low coupling, and they're independent — you can have one without the other. A standard Spring backend gets both almost for free: controllers handle HTTP, services hold logic, repositories persist, and each layer talks to the next through an interface. That layering isn't ceremony, it's the architectural expression of these two forces.
The nuance: you can over-do both. Splitting a 3-class system into 12 interfaces to keep coupling low makes change harder, not easier. The senior move is to reduce coupling at the seams that actually change, and leave the interior simple until you have a real second implementation that needs the abstraction.
Cohesion and Coupling — The Two Forces That Decide Whether Code Is Editable
Direct Answer
Cohesion is how focused a module is on a single responsibility — a highly cohesive class does one thing well. Coupling is how much one module knows about another — low coupling means a change in module A rarely forces a change in module B. The goal of good OOP design is high cohesion and low coupling: each module does one thing (cohesion) and interacts with others through narrow, stable interfaces (coupling). High cohesion makes code easier to understand and locate bugs; low coupling makes it easier to change without a cascade of edits. Together they are the single best predictor of whether a codebase stays editable as it grows — far more important than which design patterns you use.
Common Mistakes & Pitfalls
Defining the terms but not explaining the tradeoff or the failure mode. Saying 'high cohesion good, low coupling good' without showing what high coupling or low cohesion actually breaks. A second mistake: confusing the two — coupling is between modules, cohesion is within a module.
Check your understanding
Answer these without looking back at the article.
- What are the different types of coupling, ranked from worst to best?
- How do interfaces reduce coupling, and is there a coupling cost to introducing an interface?
- Is a microservices architecture always lower coupling than a monolith? When is it higher?
- How do cohesion and coupling relate to the SOLID principles — which principles target which force?
- What is afferent vs efferent coupling, and why does it matter for module design?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.