mirror of
https://github.com/github/codeql.git
synced 2026-06-15 01:41:08 +02:00
78 lines
2.7 KiB
XML
78 lines
2.7 KiB
XML
<!DOCTYPE qhelp PUBLIC
|
|
"-//Semmle//qhelp//EN"
|
|
"qhelp.dtd">
|
|
<qhelp>
|
|
<overview>
|
|
<p>
|
|
This metric provides an indication of the lack of cohesion of a class,
|
|
using a method proposed by Chidamber and Kemerer in 1994. The idea
|
|
behind measuring a class's cohesion is that most functions in well-designed
|
|
classes will access the same fields. Types that exhibit a lack of cohesion
|
|
are often trying to take on multiple responsibilities, and should be split
|
|
into several smaller classes.
|
|
</p>
|
|
|
|
<p>
|
|
Various measures of lack of cohesion have been proposed: while the basic
|
|
intuition is simple, the precise way to measure this property has been the
|
|
subject of intense debate. Rather than getting involved in this debate,
|
|
more than one such lack of cohesion measure is provided for comparison purposes.
|
|
</p>
|
|
|
|
<p>
|
|
The Chidamber and Kemerer version of lack of cohesion inspects pairs of
|
|
functions. If there are many pairs that access the same data, then the class
|
|
is cohesive. On the other hand, if there are many pairs that do not access
|
|
any common data, then the class is not cohesive. More precisely, if we let
|
|
<code>n1</code> be the number of pairs of distinct functions in a class
|
|
that do not have at least one commonly-accessed field, and let
|
|
<code>n2</code> be the number of pairs of distinct functions in a class
|
|
that do have at least one commonly-accessed field, then the lack of
|
|
cohesion measure <code>LCOM</code> can be defined as:
|
|
</p>
|
|
|
|
<pre>
|
|
LCOM = max((n1 - n2) / 2, 0)
|
|
</pre>
|
|
|
|
<p>
|
|
High values of <code>LCOM</code> indicate a worrisome lack of cohesion. The
|
|
precise value of the metric for which warnings are issued is configurable,
|
|
but as a rough indication, an <code>LCOM</code> of <code>500</code> or more
|
|
may give you cause for concern.
|
|
</p>
|
|
|
|
</overview>
|
|
<recommendation>
|
|
|
|
<p>
|
|
Classes generally lack cohesion because they are taking on more responsibilities
|
|
than they should (see [Martin] for more on responsibilities). In general, the
|
|
solution is to identify each of the different responsibilities the class is
|
|
taking on, and split them out into multiple classes, e.g. using the 'Extract
|
|
Class' refactoring from [Fowler].
|
|
</p>
|
|
|
|
|
|
|
|
</recommendation>
|
|
<references>
|
|
|
|
|
|
<li>
|
|
S. R. Chidamber and C. F. Kemerer. <em>A metrics suite for object-oriented design</em>. IEEE Transactions on Software Engineering, 20(6):476-493, 1994.
|
|
</li>
|
|
<li>
|
|
M. Fowler. <em>Refactoring</em> pp. 65, 122-5. Addison-Wesley, 1999.
|
|
</li>
|
|
<li>
|
|
R. Martin. <a href="https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view">The Single Responsibility Principle</a>. Published online.
|
|
</li>
|
|
<li>
|
|
O. de Moor et al. <em>Keynote Address: .QL for Source Code Analysis</em>. Proceedings of the 7th IEEE International Working Conference on Source Code Analysis and Manipulation, 2007.
|
|
</li>
|
|
|
|
|
|
</references>
|
|
</qhelp>
|