LCOM4 опрос о способе расчета

Question

Недавно я столкнулся с проблемой семантики при расчете LCOM4, ​​метрики, используемой для определения когерентности методов и свойств класса.

Вступление

LCOM4 является "четвертым методом расчета недостатка в сплоченности методов" и был описан Hitz и Montazeri ( http://www.isys.uni-klu.ac.at/PDF/1995-0043-MHBM.pdf) и в настоящее время является лучшим способом определить, сколько обязанностей принадлежит классу.

Я постараюсь не использовать конкретный язык разработки, потому что мой вопрос касается всех языков ООП.

Позвольте мне в основном объяснить, как это работает людям, которые не знают, с алгоритмом по умолчанию:

Class Foo {
    property a,b

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

Этот класс имеет два потока:

• атрибут a является общим для f1() и f2()
• атрибут b является общим для f3()

Таким образом, LCOM4 для Foo равен 2.

Давайте изменим, например, функцию f2(), чтобы она также разделяла свойство b.

Class Foo {
    property a,b

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

Теперь у этого класса только один поток:

• оба атрибута a и b являются общими для f1(), f2() и f3().

Это означает, что LCOM4 для Foo теперь равен 1.

LCOM4 = 0 или LCOM4 = 1 означает, что класс не имеет ни одной или только 1 ответственности, что каждый разработчик должен хотеть для своих классов, поскольку они уважают S из хороших практик S OLID.

Вы можете найти больше информации с графиками здесь: http://www.aivosto.com/project/help/pm-oo-cohesion.html

Мой вопрос

Давайте представим, что вы написали такой класс:

Class Bar {
    property a

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

... и, конечно же, при выполнении new selfЯ создаю новый экземпляр Bar, построенный с использованием метода Bar объявлен.

На основании работ Хитца и Монтазери, что такое LCOM4 моего класса Bar?

Множество инструментов метрики, которые я использую, говорят, что LCOM4=2, но для меня класс имеет только 1 ответственность, и поэтому его LCOM4 должен быть 1. Кроме того, даже если это не совсем явно, оба метода build() а также Bar() должен принадлежать тому же графику функций, что и build() звонит Bar() (ну, я знаю, это вызывает другой экземпляр, но даже если это не тот же объект, это тот же класс).

Каково ваше мнение по этому поводу?

У кого-нибудь есть ответ о том, как бороться с такого рода занятиями? (Я прочитал много документов Хитца и Монтазери, но я, вероятно, скучаю по некоторым)

Если нет ответа по этому поводу, можем ли мы улучшить способ вычисления LCOM4, ​​чтобы приблизить его к числу ответвлений класса?

Кстати, мой случай по этому поводу в PHP, но я думаю, что эта проблема касается также всех других языков ООП.

Спасибо вам, ребята,

Answer 1

Согласно предоставленной вами документации:

В дополнение к этому простому формальному улучшению определения LCOM, мы хотели бы избавиться от более семантических недостатков в определении LCOM: во-первых, весьма распространенный принцип проектирования, ограничивающий доступ к переменным экземпляра специальными методами чтения / записи. вводит аномалию этой меры: в противном случае связный класс будет давать очень высокие значения LCOM, так как все "реальные" методы будут давать изолированные узлы в графе, поскольку они больше не будут напрямую совместно использовать какую-либо переменную экземпляра.

Я интерпретирую это, поскольку статический метод и метод экземпляра разделены и, таким образом, составляют общий LCOM4 = 2. Этот результат подтверждается определением:

Они определяют отсутствие согласованности в методах (LCOM) как число пар методов, работающих с непересекающимися наборами переменных экземпляра, уменьшенное на количество пар методов, действующих как минимум на одну переменную общего экземпляра.

В вашем случае это LCOM4 = 1 + 1 - 0 = 2, как указано выше.