LCOM4 survey on calculation method

Question

I recently ran into a semantics problem in the way we calculate LCOM4, ​​the metric used to determine how the methods and properties of a class are coherent.

Introduction

LCOM4 is the “fourth method for calculating the lack of connectivity of methods” and was described by Hitz and Montazeri ( http://www.isys.uni-klu.ac.at/PDF/1995-0043-MHBM.pdf ), and currently the best way to determine how many answers a class answers.

I will try not to use a specific development language, because my question concerns all OOP languages.

Let me basically explain how this works for people who don’t know, with the default algorithm:

Class Foo { property a,b function f1() { this.a = 1 } function f2() { this.f1() } function f3() { this.b = 3 } } 

This class has two threads:

• attribute a is divided by f1 () and f2 ()
• attribute b is divided by f3 ()

So LCOM4 in Foo is 2.

Let, for example, the function f2 () also share property b.

 Class Foo { property a,b function f1() { this.a = 1 } function f2() { this.f1(); this.b = 1 } function f3() { this.b = 3 } } 

Now this class has only one thread:

• both attributes a and b are divided by f1 (), f2 () and f3 ().

This means that LCOM4 in Foo is now 1.

LCOM4 = 0 or LCOM4 = 1 means that the class does not have or has only one responsibility, which every developer should want for their classes, since they relate to S S Good OLID methods.

Further information can be found on the graphs: http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4

My question

Suppose you wrote a class like this:

 Class Bar { property a static function build() { return new self } function Bar() { this.a = 5 } } 

... and, of course, when I run new self I create a new instance of Bar created using the declared method of Bar .

Based on the work of Hitz and Montazeri, what is LCOM4 of my Bar class?

The many metric tools I use say LCOM4 = 2, but for me the class has only 1 answer and therefore its LCOM4 should be 1. In addition, even if it is not explicitly explicit, both the build() and Bar() methods should belong to the same function graph as build() calls Bar() (well, I know, it calls a different instance, but even if it's not the same object, it's the same class).

What is your opinion on this?

Does anyone have an answer on how to deal with such classes? (I read a lot of documents on Hitz and Montazeri, but I might have missed some)

If there is no answer about this, can we improve the way LCOM4 is calculated to bring it closer to the number of class responders?

By the way, my case about this is in PHP, but I think this problem applies to all other OOP languages.

Thanks guys,

Answer 1

In accordance with the attached documentation:

In addition to this, a simple official improvement in the definition of LCOM, we would like to get rid of a more semantic flaw in the definition of LCOM: firstly, it is not uncommon for a design principle to restrict access to instance variables special-purpose read / write methods introduce an anomaly this measure: otherwise a cohesive class will give very high LCOM values , since all the "real" methods are isolated nodes on the graph, since they are not directly larger than the instance variable .

I interpret this because the static method and the instance method are separate and therefore are common LCOM4 = 2. This result is supported by the definition:

They define the lack of chaining in methods (LCOM) as the number of pairs of methods that run on disjoint sets of instance variables, reduced by the number of pairs of methods that act on at least one common instance variable.

In your case, this is LCOM4 = 1 + 1 - 0 = 2, as described above.