<!DOCTYPE qhelp PUBLIC
  "-//Semmle//qhelp//EN"
  "qhelp.dtd">
<qhelp>
<overview>
<p>
This metric measures the number of incoming dependencies for each class,
 i.e. the number of other classes that depend on it.
</p>

<p>
Classes that are depended upon by many other classes typically require a lot of
effort to change, because changing them will force their dependents to change
as well. This is not necessarily a bad thing -- indeed, most systems will have
some such classes (one example might be a string class). However, classes with a high number
of incoming dependencies 
and a high number of outgoing dependencies are hard to maintain. They are hard to
change (high afferent coupling) and yet there are many reasons to
change them (high efferent coupling). This contradiction yields code that is very
hard to maintain or test.
</p>

<p>
Conversely, some classes may only be depended on by very few other classes. Again,
this is not necessarily a problem -- we would expect, for example, that the
top-level classes of a system would meet this criterion. When lower-level
classes have very few incoming dependencies, however, it can be an indication
that a class is not pulling its weight. In extreme cases, classes may even
have an afferent coupling of <code>0</code>, indicating that they are dead
code.
</p> 

</overview>
<recommendation>

<p>
It is unwise to refactor a class based purely on its high or low number of
incoming dependencies -- a class's afferent coupling value only makes sense
in the context of its role in the system as a whole. However, when combined
with other metrics such as efferent coupling, it is possible to make some
general recommendations:
</p>

<ul>
<li>
Classes with high numbers of incoming <em>and</em> outgoing dependencies
are prime candidates for refactoring (although this
will not always be easy). The general strategy is to split the class into
smaller classes, each of which has fewer responsibilities, and refactor the code
that used the original class accordingly.
</li>

<li>
Classes that have very few incoming dependencies and are not at the top level
of a system may not be pulling their weight and should be refactored.
</li>

<li>
Classes that have an afferent coupling of <code>0</code> may be dead code --
in this situation, they can often be deleted.
</li>
</ul>


</recommendation>
<references>


<li>
  M. Fowler. <em>Refactoring</em>. Addison-Wesley, 1999.
</li>
<li>
  <a href="https://en.wikipedia.org/wiki/Code_refactoring">Wikipedia: Code refactoring</a>
</li>
<li>
  <a href="http://www.jot.fm/issues/issue_2005_01/column1/">Refactoring as Meta Programming?</a>
</li>


</references>
</qhelp>
