TITLE: Thoughts on coupling and cohesion

RESPONSE: mat@mole-end.matawan.nj.us

A program is cohesive to the extent that every feature in the
problem is represented by exactly one corresponding feature in
in the solution.

A program is uncoupled to the extent that every feature in the
solution represents exactly one corresponding feature in the
problem.
 

RESPONSE: rmartin@rcmcon.com (Robert Martin)

Using the Booch method I count cohesion and coupling to be important
to the formation of class categories.  I have three rules for category
cohesion.

1.  The classes in a category must be closed together.  i.e. with
reference to the open/closed principle, the classes in a category must
be closed to the same kinds of changes.

2. The classes in a category must be reusable together.  i.e. when you
reuse one, you must reuse them all.  This makes it important to put
them into a single category so that they category can be controlled
with a version number.  It is difficult to effectively reuse a group
of classes that do not participate in version control

3. The classes in a category must share functional similarity.  i.e.
they must obey the tranditional rule of cohesion which is to do one
thing and only one thing well.  This can involve a lot of hand-waving.

These three rules are in order of priority.  Closure is most
important, Reusability second, and hand waving takes last priority.

Coupling is far more interesting.  Tranditionally we have tried to
minimize coupling.  However in OO things are not so simple.  Consider
a reusable category.  If it is successful, it will be highly coupled.
Thus, reuse implies a good type of coupling.

What types of couplings are good, and what types are bad?  Consider a
structured design.   Main loop at the top, high level modules below
the main loop.  Ever more detailed modules dangling from the bottom.
Consider that the high level design decisions, the really important
decisions, are towards the top of this scheme.  The details dangle
from the bottom.  Consider that the modules which contain the high
level decisions are dependent upon the modules which contain the
details.  Thus when a detailed module is change, the modules
containing the high level decisions, the architecture of the system,
must be changed.

When architecture depends upon details, we have bad coupling.  Instead
we want the details to depend upon the architecture.  This can be
accomplished in OO by having detailed derived classes inherit from
(depend upon) high level abstract base classes.

Through judicious use of abstract classes, we can create a dependency
structure in which the high level design decisions depend upon nothing
and are highly depended upon by the low level details.  These are good
couplings.  

Good couplings couple details to generalities.  Bad couplings couple
generalities to details.  In SD, all couplings coupled generatlities
to details, so all couplings were bad.  In OO, we try to make all our
couplings good couplings.   ;-)