I know that methods in a class should have high cohesion which roughly translates to having all the methods use all the instance variables directly or indirectly. I know that LCOM4 (Lack of cohesion)metric is useful for having a quantitative figure of how much cohesive the methods in a class are. A class with a LCOM4 value of 1 will be considered pretty good while a class with LCOM4 value of, say, 10 is considered a poorly designed class and this probably tells that we are better off decomposing the original class into 10 separate classes. All this is okay but what does the 4 signify in LCOM4 metrics?
LCOM4 – Understanding the ‘4’ in Lack of Cohesion Metric
code metricscode smellcode-qualityobject-oriented
Related Solutions
Mathematically, enumerable means "can be placed into a one to one correspondence with the natural numbers". Most representations in computing are enumerable because they are made of strings of bits, and strings of bits can be taken to denote numbers in the binary system.
Some data representations are not considered enumerable, though. For instance a floating point number is made out of bits, but we work with it as an approximation to a real number. At the binary level we can "count" through consecutive floating-point numbers, but usually this is not relevant in numeric applications.
In some other situations, enumeration is possible, but there is no agreement on an enumeration. For instance, all the objects in your run-time image constitute a finite set and can be enumerated. The garbage collector does that that when it walks through the live objects. But the application does not enumerate the set of all objects in that way without regard for type or module boundaries; it enumerates smaller of objects that are of the same kind, or related.
Usually where an enumeration exists formally, there is agreement by all parties. Here is a set of values. This one is first. That one is its successor, and so on.
In some programming languages, there exist enumerated types: some disciplined way of defining named symbolic constants which are mapped by the compiler to unique integer values. If such types are strongly typed, then these constants can only be stored in variables of their corresponding type, called an enumerated type. For instance a user-defined enumeration of type month
can only take on the values january
through december
. These are reduced to the values 0 through 11, and may allow arithmetic, such as successor(january)
producing february
, or the possibility of using the enumeration as an array index: defining an array days[january..december]
where days[january]
is, say, 31. The purpose of an enumerated type, therefore, is to serve as a subset of the natural numbers, by other names that are distinct and provide clarity of meaning (names are used instead of numeric constants) and type checking: the color red
from a color
enumeration cannot be assigned to a month
type enumeration.
The verb enumerate is also used to denote the concept of querying an API to retrieve a list of objects, usually in stepwise fashion: enumerate the network interfaces, enumerate the files in a directory, and so on. Whenever an object is in a 1:N correspondence with some other objects, it it is susceptible to supporting an enumeration API which lets us walk through those sibling objects, or retrieve them as a list. The terminology is a little murky; for instance in some cases, even if the elements are not in a particular order, but can all be visited without repetition, it is still enumeration. Some dynamic set data structures such as hash tables do not provide a particular order, and can reorganize themselves as they grown and shrink, so that the actual order varies when insertions and deletions are performed. A
can come before B
, but when we insert C
, now B
happens to come before A
because some internal reorganization took place.
In their seminal work on metric for object oriented design, Chidamber & Kemerer defined in 1993 6 metrics, among which the Weighted Methods Per Class (WMC).
Their definition is somewhat ambiguous:
Consider a Class C1, with methods M1,...Mn that are defined in the class. Let c1,...cn be the complexity of the methods. Then WMC is the sum of ci for i from 1 to n. .
Possible interpretations
Defined could mean declared, as in the definition that you have quoted. In this case, you would not count inherited methods. This would make sense because the metric intends to measure how difficult it is to write and maintain the class:
- if a class D would inherit from a base class B, but declare no methods on its own, it is definitively not difficult to maintain. It's certainly easier to maintain, even if B would have 100 methods, than another class that has a couple of methods.
- if a class B would have 10 different constructors, but class D has only 2, the maintenance effort is related to the 2 existing constructors and not to the 10 of the base class.
But defined could also mean available. In this case you should count all the inherited methods. This seems to be the probable interpretation of the authors in their article:
The larger the number of methods in a class the greater the potential impact on children, since children will inherit all the methods defined in the class.
And this can also make sense:
- a high number of methods, even inherited, makes the class more specific and less easy to reuse.
- a high number of inherited methods make the class more difficult to use, and the difficulty to maintain consistency between the many methods could also be higher.
- WMC should be relevant for class semantic (according to C&K), and inherited methods definitively contribute to class semantic.
So you should opt for this second interpretation.
Additional remarks
More recent metrics focus more on quality rather than only quantitative impact for maintenance. These are less ambiguous and take into account attributes and methods and make difference between:
- visible and private methods, to measure encapsulation, and
- inherited and available methods, to better take into account the structural benefits of inheritance.
Best Answer
LCOM4 is the fourth version of LCOM.
See http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4, under the subheading "Readings for LCOM4."