LCOM4 interrogation about way to calculate

Question

Recently, I encountered a sementic issue in the way of calculating the LCOM4, a metric used to find how the methods and the properties of a class are cohersive.

Introduction

LCOM4 is "the 4th method of calculating the Lack in Cohesion Of Methods", and has been described by Hitz and Montazeri (http://www.isys.uni-klu.ac.at/PDF/1995-0043-MHBM.pdf) and is currently the best way to define how many responsabilities a class own.

I'll try to not use a specific development language because my question is for all OOP languages.

Let me basically explain how it works to people who doesn't know, with a default algorithm:

Class Foo {
    property a,b

    function f1() { this.a = 1 }
    function f2() { this.f1() }
    function f3() { this.b = 3 }
}

This class have two flows:

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

So the LCOM4 of Foo is 2.

Let's change for example the function f2() to also share the 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 only have one flow:

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

This means the LCOM4 of Foo is now 1.

LCOM4 = 0 or LCOM4 = 1 means the class has none or only 1 responsability, which is what every developer must want for their classes, as they respect the S of the SOLID good practices.

You can find more information with graphs here: http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4

My question

Let's imagine you wrote a class like this one:

Class Bar {
    property a

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

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

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

Lots of metrics tools I use are saying LCOM4=2, but to me, the class only have 1 responsability and so its LCOM4 must be 1. Also, even if it's not really explicit, both methods build() and Bar() must belongs to the same graph of functions as build() is calling Bar() (well, I know, it's calling upon another instance, but even if it's not the same object, it's the same class).

What is your opinion on this?

Does anyone have the answer about how to deal with this kind of classes? (I read lots of documents by Hitz and Montazeri but I probably miss some)

If there's no answer about it, can we improve the way of calculating the LCOM4 to make it closer to the number of responsabilities of a class?

BTW, my case about this is in PHP, but I think this issue concerns also all others OOP languages.

Thank you guys,

Answer 1

According to the documentation you supplied:

In addition to this mere formal improvement of the definition of LCOM, we would like to get rid of a more semantic flaws in the definition of LCOM: Firstly, the not uncommon design principle to restrict accesses to instance variables to special purpose read/write methods introduces an anomaly of this measure: An otherwise cohesive class would yield very high LCOM-values, as all of the “real” methods would yield isolated nodes in the graph, as they do not directly share any instance variable anymore.

I interpret that as the static method and the instance method is separated and thus are the overall LCOM4 = 2. That result is supported by the definition:

They define Lack of Cohesion in Methods (LCOM) as the number of pairs of methods operating on disjoint sets of instance variables, reduced by the number of method pairs acting on at least one shared instance variable.

In your case that is LCOM4 = 1 + 1 - 0 = 2 as stated above.