mirror of
https://github.com/github/codeql.git
synced 2026-01-11 05:30:24 +01:00
81 lines
2.7 KiB
XML
81 lines
2.7 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
<overview>
|
|
<p>
|
|
This metric measures the number of incoming dependencies for each
|
|
class, that is 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. A class with both high afferent
|
|
coupling <em>and</em> high efferent coupling is referred to as a hub class.
|
|
Such classes can be problematic, because on the one hand they are hard to
|
|
change (high afferent coupling), yet on the other they have many reasons to
|
|
change (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 hub classes that are prime candidates for refactoring (although this
|
|
will not always be easy). The general strategy is to split the class into
|
|
smaller classes that each have fewer responsibilities, and refactor the code
|
|
that previously used the hub 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, e.g.
|
|
using the 'Collapse Hierarchy' or 'Inline Class' techniques in [Fowler]
|
|
(see the section entitled 'Lazy Class' on p.68).
|
|
</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>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|