|
Lack of Cohesion of Methods (LCOM):
Cohesion is the degree to which the methods in a class are related to one
another and work together to provide a set of behaviors. LCOM measures the
degree of similarity of methods by data inputs or the instance variables of the
class. To elaborate more, there are two main types of LCOM calculation methods
available:
LCOM1:
Take each pair of methods in the class. If they access different sets of
instance variables, increase P by one. If they share at least one variable,
increase Q by one.
LCOM1 = P - Q , if P > Q
LCOM1 = 0 otherwise
LCOM1 = 0 indicates a cohesive class.
LCOM1 > 0 indicates that the class is not quite cohesive and may need
refactoring into two or more classes. Classes with a high LCOM1 can be
fault-prone. A high LCOM1 value indicates scatter in the functionality provided
by the class. This metric can be used to identify classes that are attempting to
provide many different objectives, and consequently are likely to behave in less
predictable ways than classes that have lower LCOM1 values.
LCOM1 disadvantages
LCOM1 suffers from the following drawbacks:
- LCOM1 gives a value of zero for very different classes.
- LCOM1 is not always a valid and most appropriate way to measure cohesiveness
of a class. That’s because its definition is based on method-data interaction,
which may not be a correct way to define cohesiveness in the object-oriented
world. Moreover, very different classes may have an equal LCOM1.
- LCOM1 is defined on variable access, it's not well suited for classes that
internally access their data via properties. A class that has getters/setters
for its own internal data may show a high LCOM1. This is not an indication of
a problematic class. LCOM1 is not suitable for measuring such classes.
To overcome the problems of LCOM1, two additional metrics have been proposed:
LCOM2 and LCOM3.
A low value of LCOM2 or LCOM3 indicates high cohesion and a
well-designed class. It is likely that the system has good class
subdivision implying simplicity and high reusability. A cohesive
class will tend to provide a high degree of encapsulation.
A higher value of LCOM2 or LCOM3 indicates decreased
encapsulation and increased complexity, thereby increasing the
likelihood of errors.
Which one to choose, LCOM2 or LCOM3? This is a matter of taste.
LCOM2 and LCOM3 are similar measures with different formulae.
LCOM3 varies in the range [0,1] while LCOM2 is in the range
[0,2]. LCOM2>=1 indicates a very problematic class. LCOM3 has no
single threshold value.
It is a good idea to remove any dead variables before
interpreting the values of LCOM2 or LCOM3. Dead variables can
lead to high values of LCOM2 and LCOM3, thus leading to wrong
interpretations of what should be done.
Definitions for LCOM2 and LCOM3
m number of procedures (methods) in class
a number of variables (attributes) in class
mA number of methods that access a variable (attribute)
sum(mA) sum of mA over attributes of a class
Implementation details. m is equal to WMC. a contains all variables whether
Shared or not. All accesses to a variable are counted.
LCOM2
LCOM2 is counted as the percentage of methods that do not access
a specific attribute averaged over all attributes in the class.
LCOM2 = 1 - sum(mA)/(m*a)
If the number of methods or variables is zero, LCOM2 is undefined and displayed
as zero.
LCOM3 (Henderson-Sellers)
LCOM3 = (m - sum(mA)/a) / (m-1)
LCOM3 varies between 0 and 2. Values 1..2 are considered alarming.
In a normal class whose methods access its own variables, LCOM3
varies between 0 (high cohesion) and 1 (no cohesion). A LCOM3
value of 1 indicates high lack of cohesion.
When LCOM3=0, each method accesses all variables. This indicates
the highest possible cohesion.
Coupling between Object Classes (COB):
CBO = number of classes to which a class is coupled
Two classes are coupled when methods declared in one class use
methods or instance variables defined by the other class. Only
method calls and variable references are counted. Other types of
reference, such as use of constants, calls to API declares,
handling of events, use of user-defined types, and object
instantiations are ignored. If a method call results in calling
(using) other classes, all the classes to which the call can go
are included in the coupled count.
High coupling between object classes means modules depend on
each other too much and will be hard to reuse. The more
independent a class is, the easier it is to reuse it in another
application. In order to improve modularity and promote reuse,
inter-object class couples should be kept to a minimum. The
larger the number of couples, the higher the sensitivity to
changes in other parts of the design, and therefore maintenance
is more difficult.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
