Structured design ranks coupling from content coupling down to data coupling, and cohesion from coincidental up to functional. Walk through those two scales and explain how you would actually use them when reviewing a module boundary.

## Where the scales come from Larry Constantine and Ed Yourdon (*Structured Design*, 1970s; earlier in Stevens/Myers/Constantine 1974) proposed **ordinal scales** to make "low coupling, high cohesion" concrete enough to review. They predate objects entirely, which is why they transfer cleanly to functions, classes, packages, and services alike — nothing in them assumes a language or paradigm. ## Coupling scale (worst first) 1. **Content coupling (pathological).** Module A relies on or modifies module B's internals: writing B's private data, jumping into the middle of B, depending on B's local variable layout. Modern forms: reflection into private fields, monkey-patching, mutating an object returned by reference that the owner still uses, depending on a subclass's knowledge of a superclass's private state. *Why worst:* any internal change to B silently breaks A, and the compiler/tests may not catch it. 2. **Common coupling.** Modules share globally accessible mutable data — a global variable, a singleton holding state, a shared mutable configuration blob, a shared database table written by several modules. *Why bad:* no module owns the invariant; reasoning requires knowing every writer; concurrency and test isolation collapse; changing the shape of the shared data affects everyone at once. 3. **External coupling.** Modules are jointly bound to an externally imposed detail: a device protocol, a file format, a fixed wire layout. Unavoidable at the edges; the fix is to confine it to one adapter rather than let it spread. 4. **Control coupling.** A passes a value whose purpose is to select which internal path B takes — the classic `render(data, isPdf)` or `process(order, mode = 2)`. *Why bad:* the caller must know B's internal branching structure, so B's alternatives are not really hidden; adding a third mode changes both sides; the flag argument makes call sites unreadable. *Fix:* two named operations, or polymorphism/strategy so the choice is made once at construction. 5. **Stamp coupling (data-structure coupling).** A passes a whole composite record when B only needs one or two fields — `sendEmail(customer)` when only `customer.email` is used. *Why bad:* B is now compiled/tested against the composite's shape and may accidentally start using more of it; it also drags an unnecessary dependency (and potentially sensitive data) across the boundary. *Nuance:* passing a cohesive domain value object is often *better* than exploding it into five primitives — stamp coupling matters when the composite is incidental to the callee's job, not when it *is* the concept. 6. **Data coupling (best of the classic scale).** Only the specific primitive/value parameters needed are passed, and nothing is shared implicitly. Later writers add **message coupling** below data coupling: interaction only through messages/events with no shared types beyond the message itself. And **no coupling** at the bottom, which is only achievable for genuinely independent modules. Orthogonal factors the scale doesn't capture, which you must layer on in review: **direction** (does the dependency point toward the more stable side?), **cycles** (A↔B is far worse than either alone), **fan-out** (how many things must exist for this to run), and **volatility** of the depended-upon thing. ## Cohesion scale (worst first) 1. **Coincidental.** Elements grouped for no reason — `Utils`, `Helpers`, `Common`. Nothing predicts what's inside; every team edits it; it becomes a dependency magnet. 2. **Logical.** Elements in the same broad category, selected by a flag through one entry point — e.g., one `handleInput(kind, payload)` that internally switches on kind for mouse, keyboard, and network input. Note this is the mirror image of control coupling: logical cohesion inside creates control coupling at the interface. 3. **Temporal.** Grouped because they happen at the same time — `initialize()`, `shutdown()` that touch a dozen unrelated subsystems. The only relationship is the clock, so the module changes whenever *any* subsystem changes. 4. **Procedural.** Grouped because they execute in a certain order, but operate on different data. Sensitive to reordering and to changes in any step. 5. **Communicational (informational).** All elements operate on the same data set — e.g., all operations on a customer record. This is roughly the cohesion of a well-formed abstract data type and is a perfectly good target in practice. 6. **Sequential.** Output of one element feeds the next, all on the same data — a pipeline stage. 7. **Functional (best).** Every element contributes to one single, well-defined task; you can name the module in a verb phrase with no conjunctions. **Where SRP fits.** Robert Martin's Single Responsibility Principle — "a module should have one, and only one, reason to change", later sharpened to "be responsible to one actor/stakeholder" — is essentially a change-oriented restatement of high cohesion. The classic taxonomy asks *what relates these elements?*; SRP asks *who requests changes to them?* The second question is more actionable, because two functions that look related can still be owned by the accounting department and the operations department, and merging them guarantees conflicting change requests. At component scale the same idea becomes the **Common Closure Principle** (classes that change for the same reasons at the same times belong in the same component). ## How to actually use these in review They are diagnostic vocabulary, not a metric to maximize. A workable procedure: 1. **Name the level.** "This is control coupling" is more actionable than "this feels wrong", and less arguable. 2. **Name the change that would hurt.** "When we add the third export format, both the caller and the callee change, and every call site's boolean becomes ambiguous." The scale's ordering is a proxy; the concrete future change is the argument. 3. **Propose the specific move.** Flag argument → two named methods or a strategy. Global state → explicit parameter or injected collaborator. Utils class → split by actual client and move each function next to its user. Temporal cohesion → let each subsystem own its own lifecycle and have the orchestrator call each one. Stamp coupling → narrow the parameter to what's used, *unless* the composite is the domain concept. 4. **Weigh the cost.** Moving one step up the scale can cost readability (five primitive parameters instead of one object) or performance (copying instead of sharing). Accept a worse level deliberately and write down why. 5. **Look for the paired symptom.** Logical cohesion inside almost always shows up as control coupling outside; a split responsibility shows up as high coupling plus co-change in git history. Fixing one usually fixes the other. ## Limits The scales are coarse and ordinal — there is no arithmetic, no aggregation into a single number, and "stamp" vs. "data" arguments can become pedantic. They also ignore direction, cycles, and volatility, which often matter more than the category. **Connascence** (Meilir Page-Jones) is the finer instrument: it names the *kind* of agreement two elements share (name, type, position, meaning, algorithm, timing, execution order, identity) and adds strength, degree, and locality as separate dimensions. Use the classic taxonomy for shared vocabulary and quick triage; use connascence when you need to argue precisely about a specific coupling and its remedy.