From the author of

From the author of

Introducing Coupling and Cohesion

Last month I described how the history of programming languages is one of
gradually rising levels of abstraction. Machine instructions are grouped into
expressions, chunks of code are grouped into structured programming structures,
and chunks of data are grouped into classes. For a unita line of code, a
method, a classto be easily maintainable, you want everything in it to be
on a single topic, and only things on that topic are in that unit.

Generally, no matter what size the unit is, a designer should strive to
decrease dependencies between units, while increasing the dependencies
within a unit. When two units depend on each other, it's called
coupling, and it's a bad thing. It means that you can't
understand one unit without understanding the other, which makes maintenance
difficult. It also means that you can't pick up one unit without the other,
which makes it hard to reuse and maintain.