Information Technology Reference
In-Depth Information
Complexity has been shown to correlate with defects. Use your
inspections to monitor a code base's complexity values, and take action
to monitor trends or lower defect risks with test cases and refactoring.
There are other useful metrics that blossomed in the latter part of the
twentieth century. Have you ever noticed that objects that have a lot of
dependencies on other objects become somewhat
brittle?
If one of
their dependencies changes, the object itself may break. From the
other direction, when you change an object that every other object in a
system depends on, it creates issues elsewhere. (This tendency is com-
monly referred to as the “collateral damage” effect.) It is important to
be poised for unanticipated change (the one constant), and you don't
want dependencies holding you back from creating changes that you
wish to make.
Two metrics most helpful in determining over-coupling are known
as
Afferent Coupling
and
Efferent Coupling
(sometimes called
Fan
In
and
Fan Out,
respectively). These simple integer metrics count the
relationships to or from objects. Both Afferent and Efferent Coupling
signify an architectural maintenance issue: Either an object has
responsibility to too many other objects (highly afferent) or the object
isn't sufficiently independent of other objects (highly efferent).
These dependency metrics can be extremely helpful in determin-
ing the risk in maintaining a code base. Objects or namespaces/pack-
ages with too much responsibility present a risk when those objects
need to be changed. If their behavior changes somehow, other objects
in the software system may stop functioning as intended. Objects that
are highly dependent on other objects present brittleness in the face of
change—they too may stop functioning as intended if one of their
imported objects changes, even in subtle ways.
What's more, both Afferent and Efferent Coupling can be com-
bined to form an
Instability
value. For example, the following equa-
tion can represent an object's (or namespace's/package's) level of
instability in the face of change. Note that a value of one is instable,
while a value of zero is stable.
