Coupling and Cohesion

Two measurements

Concept

Cohesion

How strongly the things inside one type relate to each other. A type whose fields and methods all serve one job is cohesive. A type holding a database connection, a date formatter and a discount rule is not.

Concept

Coupling

How much one type must know about another to work. If changing B's internals forces a change in A, A is tightly coupled to B.

Nearly every principle later in this track is one of these two wearing a specific hat. Single Responsibility is cohesion. Dependency Inversion is coupling. Interface Segregation is both.

The kinds of coupling that hurt

Kind	Looks like	Why it bites
Concrete	A holds a `new StripeGateway()`	B cannot be swapped or faked in a test
Structural	A reads `b.getC().getD().value`	A breaks when C or D changes shape
Temporal	`init()` must be called before `use()`	Nothing in the type system says so
Shared mutable state	Both write the same object	Order of operations becomes load-bearing

Four flavours, roughly in order of how often they cause trouble.

Structural coupling has a well-known rule of thumb: talk only to your immediate neighbours. A chain like order.getCustomer().getAddress().getPostcode() means the caller knows the shape of three types it has no business knowing. Asking the order for what you actually want — its delivery postcode — leaves one relationship instead of three.

Coupling cannot be removed, only moved

Suppose PaymentProcessor constructs a StripeGateway directly. That is concrete coupling, and the usual fix is to define a PaymentGateway interface and have the processor depend on it instead.

Notice what happened. The processor is now coupled to an interface you own rather than to a vendor's class — but something, somewhere, still has to decide that the real gateway is Stripe. The coupling moved to the composition root, where it is one line that is easy to find and easy to change. It did not disappear.

A quick self-check

Could I test this class without starting a database, a server or a clock? If not, what is it coupled to?
If I renamed a private field on that other class, would this one still compile?
Does this class have fields that are only used by half its methods? That is low cohesion.
Could I describe this class's job without listing its methods?