In software design, what do the terms "coupling" and "cohesion" mean, and why is the standard goal low coupling with high cohesion?
answer
- Between modules = coupling; inside a module = cohesion
- Things that change together live together
- Bad boundary raises coupling AND lowers cohesion
- Depend on stable, not volatile; avoid cycles
- Indirection ≠ decoupling
basics
~20 sCoupling is how much one module depends on another; cohesion is how well the things inside one module belong together. Low coupling means changing one module rarely forces changes elsewhere; high cohesion means each module does one clear job.
solid answer
~50 sCoupling measures the strength of dependency **between** modules; cohesion measures the relatedness of elements **within** a module. They are the two halves of one question: where should the boundary go? Low coupling limits the blast radius of a change — if module A only knows a small, stable interface of B, B's internals can be rewritten without touching A. High cohesion means everything inside a module changes for the same reason, so a feature change lands in one place instead of being smeared across five. The two are linked: if you split a genuinely cohesive concept in half, you create a chatty, tightly coupled pair; if you merge unrelated concepts to "reduce" coupling, you get a low-cohesion blob that everyone must edit. The real target is not zero coupling (that's zero functionality) but *loose and intentional* coupling along boundaries that match how the system actually changes.
code
pseudocode · 12 lines// Tight coupling + low cohesion: caller knows B's internals and B mixes concerns
report.rows = db.connection.rawQuery("SELECT ...") // reaches through B
report.formatAsPdf() // unrelated concern inside
report.emailTo("[email protected]") // and another
// Looser coupling + higher cohesion: narrow contract, one job per module
interface OrderQueries { fun monthlyTotals(month): List<Total> }
class MonthlyReport(private val queries: OrderQueries) { // knows an abstraction
fun build(month) = Report(queries.monthlyTotals(month)) // one job: build data
}
// rendering and delivery live in their own modulesgo deeper
Define both terms correctly and give one concrete example of each (a class that does one job; a class reaching into another class's fields). Say why it matters: changes stay local and code is easier to test.
Connect the two: explain that a badly placed boundary raises coupling and lowers cohesion simultaneously, and use co-change in git history as evidence. Mention direction, stability, and cycles.
Frame boundary placement as a change-cost optimization, name the taxonomies (content→data coupling, coincidental→functional cohesion), and note that indirection without variability is not decoupling. Give a refactor you actually did and its measured effect.
Scale the argument: the same metric decides class boundaries, package boundaries, and service boundaries; team topology and release cadence are the real constraints. Discuss when you deliberately accept coupling (shared kernel, performance) and how you keep it explicit and reversible.
## The two words A **module** here is any unit with a boundary: a function, a class, a package, a library, a deployable service. The same two properties are evaluated at every scale, which is exactly why they are the bridge from code-level design to architecture. **Coupling** = the degree of interdependence *between* two modules. Concretely: how much does A need to know about B, and how likely is a change in B to force a change in A? Signals of tight coupling include reaching into another module's internal data, sharing mutable global state, depending on a concrete implementation rather than an abstraction, and depending on B's internal ordering or timing. **Cohesion** = the degree to which the elements *inside* one module belong together and serve one purpose. Signals of high cohesion: the functions operate on the same data, they are changed by the same kind of request, and you can name the module without using "and", "manager", "util", or "helper". ## Why the goals point in those directions 1. **Cost of change.** Most software cost is modification, not first authorship. Low coupling means a change stops at a boundary; high cohesion means a change is *localized* to one boundary rather than scattered. Together they minimize the number of places you must edit and re-verify per change. 2. **Comprehensibility.** You can reason about a loosely coupled module by reading it plus the interfaces it uses, instead of the whole system. 3. **Independent work.** Loose coupling lets two people (or two teams) work in parallel behind a stable contract. 4. **Testability.** A module with few, abstract dependencies can be exercised with simple substitutes; one wired to a database, clock, and network cannot. 5. **Reuse and replaceability.** A cohesive module with a narrow interface can be swapped or reused; a blob cannot. ## They are not independent knobs This is the part juniors usually miss. Coupling and cohesion are two views of the *same* boundary placement: - Split one cohesive responsibility across two modules → the two must now talk constantly about shared details → coupling goes **up** while cohesion goes **down**. (Classic symptom: two classes that are always edited in the same commit.) - Merge unrelated responsibilities into one module to remove a dependency → coupling between modules drops on paper, but the module now has low cohesion, and *everyone* has to touch it, so effective coupling across the team goes up. So the correct framing is: **choose boundaries so that things that change together live together, and things that change for different reasons are separated.** Coupling/cohesion are how you score a proposed boundary, not knobs to be turned independently. ## Common false targets - **"Minimum coupling" is not the goal.** A system with zero coupling does nothing. The goal is that each dependency is deliberate, narrow, one-directional where possible, and pointed at something more stable than the depender. - **Fewer files ≠ higher cohesion.** Cohesion is about *conceptual* relatedness, not physical proximity. - **An interface does not automatically decouple.** If the interface exposes the same internal details, or if there is exactly one implementation that both sides must agree on semantically, you have added indirection without removing dependency. Coupling is about *knowledge*, not about syntax. ## Direction and stability matter Two dependencies of equal "strength" are not equally bad. A dependency pointing at something **stable** (a well-defined, rarely-changing abstraction) costs little; a dependency pointing at something **volatile** (a specific vendor SDK, a UI layout, a wire format) costs a lot. And **cyclic** coupling (A → B → A) is worse than either direction alone, because neither module can be understood, tested, released, or replaced independently. Acyclic, one-directional dependencies pointed from volatile toward stable are the practical shape of "low coupling". ## How to spot it without theory - Look at commit history: files that always change together but live apart indicate a cohesion problem; files that must change whenever an unrelated feature ships indicate a coupling problem. - Try to describe the module in one sentence with no conjunctions. If you can't, cohesion is low. - Ask "what do I have to know about B to use it correctly?" The longer that list, the tighter the coupling — including things that aren't in the signature, like required call order or hidden shared state.
- If low coupling is good, why not make every dependency go through an interface?Because indirection is not decoupling. An interface only helps when it hides something that can vary and is owned by the consumer's side of the boundary. Adding an interface with one implementation, that mirrors that implementation method-for-method, adds a file and a jump for the reader while leaving the same semantic dependency. Use abstraction where volatility or substitution actually exists.
- Two classes are loosely coupled but you always edit both in the same pull request. What's the problem?That's a cohesion problem masquerading as good design: one responsibility has been split across two modules. Co-change in version control is the strongest empirical signal that a boundary is in the wrong place. Merge them, or move the shared reason-for-change into one of them.
- Does high cohesion mean a module should be small?No. Cohesion is about singleness of purpose, not line count. A 500-line module implementing one algorithm can be highly cohesive; a 40-line 'Utils' class with four unrelated helpers is not.
Think of an office building. Cohesion is putting all of accounting on one floor instead of scattering accountants across five floors. Coupling is how often accounting must walk to legal to get anything done. You want each floor self-sufficient (high cohesion) and inter-floor trips rare and via a simple reception desk, not by wandering into people's drawers (low, narrow coupling).
saying these in an interview costs you the question
- Saying the goal is "no coupling" — a system with no dependencies has no behavior.
- Treating coupling and cohesion as independent dials rather than two scores of the same boundary placement.
- Claiming that wrapping a class in an interface automatically reduces coupling, regardless of who owns the interface or whether anything varies.
- Equating cohesion with file size or class length.
- Ignoring dependency direction and cycles — A↔B is much worse than A→B even at equal "strength".
- Using "Manager", "Helper", or "Utils" names and calling the result cohesive.