#begin

Chapter 10 is about cohesion. David defines it as “the degree to which the elements inside a module belong together.” Simple enough on paper, right? Until you’re staring at a 2000-line class that does authentication, sends emails, formats dates, and somehow also manages a shopping cart. That thing has the cohesion of a dumpster fire.

The core idea David is pushing here is that cohesion and coupling are deeply related. High cohesion and low coupling are the twin pillars of good modular design. You can’t really have one without the other. A module that does too many unrelated things will inevitably drag in dependencies from all over the place and before you know it your spaghetti has reached Flying Spaghetti Monster proportions. Delicious to some, absolutely terrifying to maintain.

What Cohesion Actually Means

David distinguishes between different kinds of cohesion. On the low end you have coincidental cohesion — a module that groups things together purely by accident, or worse, because someone just kept dumping code in the same file. On the high end you have functional cohesion — where every element in the module exists to serve one single, well-defined purpose. That’s where you want to be.

Think of it this way. A class called UserManager that handles login, password reset, profile pictures, email verification, preferences, and subscription tiers is not a manager — it’s a hostage situation. Each of those concerns belongs in its own module.

Cohesion Is About Reason to Change

One of the most practical lenses David puts on cohesion is about change. A cohesive module should have one reason to change. If you’re changing your PaymentService because the marketing team updated the email template, something has gone horribly wrong. That’s a smell. That’s two things living together that have no business sharing a roof.

This connects nicely to the Single Responsibility Principle from uncle Bob. David is making the same argument but grounding it in the broader engineering discipline rather than just OOP dogma. It’s not just good object-oriented style — it’s fundamental to building software that you can actually reason about and modify without breaking six other things.

The Practical Cost of Low Cohesion

Here’s what low cohesion actually costs you in practice. It makes code harder to understand, because there is no clean mental model for what a module does. It makes testing harder, because you need to set up a bunch of unrelated state just to test one small behaviour. And it makes reuse basically impossible, because your “utility” class has so many dependencies baked in that you can’t pull it out without taking half the codebase with it.

I’ve seen this pattern play out many times. Someone writes a helper function, shoves it in a Utils class, and then every other developer on the team does the same. A year later that Utils class is a Frankenstein of unrelated methods that nobody dares to touch. Classic.

Cohesion and Testability

David ties cohesion back to testability, which I really appreciate because it makes the abstract concrete. If you can’t write a simple unit test for a module without mocking half the universe, that’s a cohesion problem. The seams are in the wrong places. High cohesion makes modules independently testable, which makes your whole codebase more robust and easier to evolve.

This is also why cohesion matters so much for CI/CD pipelines. Small, focused modules with clear boundaries are much easier to build, test, and deploy in isolation. That’s how you get fast feedback. That’s how you keep your pipeline from becoming a 45-minute nightmare that everyone on the team ignores.

Takeaway

Cohesion is one of those things that is easy to understand in theory and surprisingly hard to apply consistently. It requires discipline. It requires resisting the urge to just add one more method to that existing class because it’s convenient. David makes a compelling case that this discipline pays off massively over time — in understandability, testability, and the ability to change your software safely and quickly.

In short: keep things together that belong together, and separate everything else. Your future self will thank you. Your colleagues will thank you. The poor soul maintaining this code in three years will probably still complain about something, but at least it won’t be cohesion. 

#end

01010010 01110101 01100010 01100101 01101110