In software design, what do the terms "cohesion" and "coupling" mean, and what is the standard rule of thumb about them?

## The two words A **module** here is any unit of grouping — a function, a class, a package, a service, a deployable component. The two classic quality measures of a modular decomposition, introduced by Larry Constantine in the 1960s–70s (structured design) and still the vocabulary used today, are cohesion and coupling. **Cohesion — internal.** How closely related are the responsibilities *inside* one module? A module with high cohesion does one thing. You can name it in a short noun phrase without "and": `PriceCalculator`, `InvoiceRepository`. A module with low cohesion is a grab bag: `Utils`, `Helpers`, `Manager` — you can only name it with vague words or a list. **Coupling — external.** How much does one module depend on another? Coupling is a property of a *pair* (or a graph) of modules. Key question: **if B changes, how likely is A to break or need editing?** The more A relies on B's internal details (fields, table schema, order of calls, global state), the tighter the coupling. ## The rule and why it holds > Maximise cohesion within modules, minimise coupling between them. Why it matters, concretely: - **Change locality.** The whole point of modularity (David Parnas, 1972) is that a design decision likely to change should be hidden inside one module, so a change touches one place. Low coupling = small blast radius. - **Comprehension.** A cohesive module can be understood without reading the rest of the system. Low cohesion forces you to hold unrelated concerns in your head at once. - **Testing.** Low coupling means fewer collaborators to stub/mock; high cohesion means the tests for one behaviour live in one place. - **Reuse and replacement.** You can only reuse or swap out a unit that has one purpose and few incoming assumptions. - **Parallel work.** Teams can work independently only if their modules do not constantly force each other to change (this is the design half of Conway's Law). ## The two are coupled to each other They are not independent knobs. If you split one concern across three modules, each module is now less cohesive *and* the three must communicate constantly, raising coupling. Conversely, if you smash everything into one giant module, coupling between modules drops to zero — but internal cohesion collapses and you have just hidden the coupling inside the module, where no tool can see it. This is why "zero coupling" is not the goal: a system of modules that never talk does nothing. The goal is the **weakest sufficient dependency**. ## Degrees, not booleans Both are spectra with classic named levels: - Cohesion, worst → best: coincidental, logical, temporal, procedural, communicational, sequential, **functional**. - Coupling, worst → best: content, common, external, control, stamp, **data** (plus "message coupling" / no coupling at the far end). You do not need to recite these in most interviews, but knowing they are ordered scales shows you understand these are gradients you move along, not properties you toggle. ## Smells of getting it wrong - A change to one feature requires editing five files in five packages → low cohesion (**shotgun surgery**). - One module has to change for many unrelated reasons → low cohesion (**divergent change**); this is the same idea as the Single Responsibility Principle. - A module reaches through another object's fields: `order.getCustomer().getAddress().getCity()` → high coupling (**inappropriate intimacy** / violation of the Law of Demeter). - Two services share a database table and both write it → high coupling (common coupling) even though there is no code-level import. ## Edge cases and nuance - **Coupling is unavoidable and sometimes desirable.** Depending on a *stable abstraction* (an interface, a versioned contract) is cheap coupling. Depending on a *volatile implementation detail* is expensive coupling. Judge coupling by the likelihood and cost of the change it propagates, not by counting arrows. - **Cohesion is relative to the axis of change.** Robert Martin's phrasing of SRP — "gather things that change for the same reason, separate things that change for different reasons" — makes cohesion depend on *who asks for changes*, not on surface similarity. Two functions that both format text may look similar yet belong apart if one serves accounting and the other serves marketing. - **Distributed systems do not fix coupling.** Splitting a tangled codebase into services over HTTP converts compile-time coupling into runtime coupling, usually making it worse (the "distributed monolith"). The decomposition must follow cohesive boundaries first.