Coupling & Cohesion — Interactive OOP

Explore Topics

🧭

The Hidden Metrics

A 1974 quality model that still defines "good design"

🔬 Spectrum Lab — three lenses on the same grid

Drag the marker on each spectrum. The code panel below morphs to show that level's canonical example, plus a design verdict for the combined coordinate.

Coupling

worst → best

Cohesion

worst → best

Contentcoupling·Coincidentalcohesion
// COUPLING — A modifies B's private internals (reflection / direct field access).Field f = Box.class.getDeclaredField("value");
f.setAccessible(true);
f.setInt(box, 99);
// COHESION — Members of the class are bundled at random — pure junk drawer.class Utils {
    void printDate()       { ... }
    double computeSqrt(int) { ... }
    void sendEmail(String) { ... }
}

Design verdict

Worst corner

Coordinate (Content, Coincidental)

Rank 7/7 coupling, rank 7/7 cohesion.
(rank 1 = best, 7 = worst)

🧭

The Hidden Metrics

A 1974 quality model that still defines "good design"

In 1974, three IBM engineers — Wayne Stevens, Glenford Myers and Larry Constantine — published "Structured Design", a paper that asked a deceptively simple question: what makes one decomposition of a program better than another? Their answer was a pair of metrics. Coupling measures how strongly modules depend on each other; cohesion measures how unified the work inside one module is. Decades before SOLID and GRASP, this two-axis model gave every design decision a coordinate. Today, every named principle you know is really an instruction for moving toward "low coupling × high cohesion" on the 2-D grid.

Key Ideas

Stevens, Myers, Constantine — "Structured Design", IBM Systems Journal (1974)
Coupling: strength of inter-module dependencies (lower is better)
Cohesion: degree to which a module's members serve one purpose (higher is better)
Seven coupling levels, seven cohesion levels — a 7×7 grid of design quality
SOLID, GRASP, DRY, KISS — all are SHORTCUTS for navigating this same grid
Originally about procedural modules; the metric transfers cleanly to classes

Strengths

✦Predates and underpins every modern OO principle — historical foundation
✦Provides a CONTINUOUS quality scale (not binary "good/bad")
✦Maps directly to maintenance cost — ripple-change studies validate the metric
✦Language-agnostic: works for Java, Python, microservices, even hardware modules

Weaknesses

△The seven levels are nominal categories — there is no precise quantification
△Different authors disagree on edge cases (External coupling: a level or a Common variant?)
△Easy to misuse as "more decomposition is always better" — leads to over-fragmentation
△Cohesion is harder to measure than coupling; partly subjective

Used in:Every static-analysis tool you have used — SonarQube, NDepend, JArchitect, Code Climate — measures coupling automatically (fan-in, fan-out, instability, afferent/efferent metrics). The 1974 categories are the conceptual model behind those modern numbers.

Code Snippets

Quiz

The Hidden Metrics Quiz

QUIZ 1/4

In what year, and in which publication, was the formal seven-level coupling/cohesion model introduced?

Diagrams

The Coupling Ladder — 7 rungs, worst at the top

Loading diagram...

The Cohesion Ladder — 7 rungs, worst at the top

Loading diagram...

How SOLID and GRASP move you on the grid

Loading diagram...

Practice

Pin the Coupling — drag each Java snippet onto the coupling rung it represents.

EXERCISE 1/5

Reflection sets a private field of another class

Two classes increment GlobalCounter.value

svc.process(true) — boolean selects branch

printReceipt(Order o) uses only o.total of 6 fields

printReceipt(double total)

sale.close() — Sale decides everything itself

Formatter and Logger never reference each other

Content (worst)

Common

Control

Stamp

Data

Message

None (best)

Pin the Cohesion — drag each class description onto the cohesion rung it represents.

EXERCISE 2/5

Utils: printDate(), computeSqrt(), sendEmail()

Validator.validate(kind, data) — type-switch over kind

Startup.boot(): openLog, warmCaches, greet, readConfig

Report: fetchFromDb -> formatHtml -> emailToManager (order matters, different data)

Sale: addItem, applyTax, total — all touch the same subtotal

Parser: read(path) -> normalize(text) -> parse(text)

PriceCalculator.compute(base, tax, discount) — one return value

Coincidental (worst)

Logical

Temporal

Procedural

Communicational

Sequential

Functional (best)

Coupling & Cohesion myths and misconceptions

EXERCISE 3/5

Inheritance always couples a subclass more tightly to its parent than composition would.

Static utility methods always lower coupling because they have no state.

All shared global variables are Common coupling.

You can have high cohesion AND high coupling at the same time.

Splitting a low-cohesion class into many single-purpose classes always improves the design.

A class that takes only primitives in its constructor cannot have Stamp coupling.

Refactor Stamp coupling to Data coupling

EXERCISE 4/5

// BEFORE — Stamp coupling: takes whole Order, uses only total.
static void printReceipt(Order o) {
    System.out.println(o.total);
}

// AFTER — Data coupling: takes only what is needed.
static void printReceipt( total) {
    System.out.println();
}

// CALL SITE — update to match:
Order o = new Order(...);
printReceipt();