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.