Cohesion vs. Coupling

Two forces shape every codebase: coupling and cohesion.

Coupling is the connection between modules. High coupling means changing one forces you to change others — pull one thread and the rest follows. Everyone knows to reduce coupling. Fewer dependencies, cleaner interfaces, looser connections.

But the way you actually get there is through its counterpart. Cohesion is the relationship inside a module. High cohesion means everything in a class belongs together and changes for the same reason. Low cohesion is an OrderProcessor that handles payment validation, inventory checks, and notification emails — unrelated concerns packed into the same container, waiting to tangle. Split them into a PaymentValidator, an InventoryChecker, and a NotificationService, each with one reason to change, and the right boundaries become obvious.

High cohesion often solves coupling problems on its own. When you group things that change together, you create islands of logic — easy to understand, safe to modify. The ripples stop at the boundary because nothing outside needs to care about what's inside.

So the question isn't just "How are things connected?" It's "Why are they together in the first place?" A system with low coupling but low cohesion is loosely connected parts with no clear story. A system with high cohesion and low coupling is one where every piece does one thing well — and the connections between them stay honest.