Developers I encounter usually have a good grasp of coupling—not only what it means, but why it’s a problem. I can’t say the same thing about cohesion. One of the sharpest developers I know sometimes has problems with the concept, and once told me something like “that word doesn’t mean much to me.” I’ve come to believe that a big part of the problem is the word “cohesion” itself. “Coupling” is something everyone understands. “Cohesion,” on the other hand, is a word that is not often used in everyday language, and that lack of familiarity makes it a difficult word for people to hang a crucial concept on.

I’ve had some success teaching the concept of cohesion using an unusual approach that exploits the word’s etymology. I know that sounds unlikely, but bear with me. In my experience, it seems to register well with people.

Cohesion comes from the same root word that “adhesion” comes from. It’s a word about sticking. When something adheres to something else (when it’s adhesive, in other words) it’s a one-sided, external thing: something (like glue) is sticking one thing to another. Things that are cohesive, on the other hand, naturally stick to each other because they are of like kind, or because they fit so well together. Duct tape adheres to things because it’s sticky, not because it necessarily has anything in common with them. But two lumps of clay will cohere when you put them together, and matched, well-machined parts sometimes seem to cohere because the fit is so precise. Adhesion is one thing sticking to another; cohesion is a mutual relationship, with two things sticking together.

This is also why we refer to a sound line of reasoning, for example, as coherent. The thoughts fit, they go together, they relate to each other. This is exactly the characteristic of a class that makes it coherent: the pieces all seem to be related, they seem to belong together, and it would feel somewhat unnatural (it would result in tight coupling!) to pull them apart. Such a class exhibits cohesion. No glue is required, you don’t have to build extra code to make the pieces fit together; the pieces hang together naturally because they’re closely related. In contrast, sometimes a class will seem to have its fingers in way too many parts of your system. Such a class is adhesive, and that’s not what we’re looking for.

And whereas coherent means things fit well together, we use the word “adherent” to refer to a follower, and there’s a connotation that the follower isn’t necessarily wanted: a hanger-on.

There’s another common word that stems from the same root: “inherent”. Something that adheres sticks to something else, and two things that are coherent mutually stick to each other, but something that is inherent isn’t stuck to something so much as it’s embedded: it is an integral part of the other thing, tightly and inextricably bound. Although you don’t hear them very often, the two sister words “inhere” and “inhesion” are real words, as well.

So cohesion/cohesive/coherent occupy the middle territory between the sort of arbitrary, forced relationship of adhesion/adhesive/adherent and the integral, unbreakable relationship of inhesion/inhesive/inherent. That mental picture often helps me make wise decisions when I’m designing and refactoring. I want to build classes that are cohesive, not adhesive.