Я искал в Интернете некоторые предложения по пороговым значениям для следующих известных показателей программного продукта:
Однако мне не удалось найти ни одного. Меня особенно интересует первый. Кто-нибудь что-нибудь знает об этом? Заранее спасибо, Мартин
NDepend предлагает следующее:
http://www.ndepend.com/Metrics.aspx#LCOM
Этот справочник содержит значения для LCOM и LCOMHS. Это говорит
- LCOM = 1 – (сумма(MF)/M*F)
- LCOM HS = (M – сумма(MF)/F)(M-1)
Где:
- M — количество методов в классе (учитываются как статические, так и экземплярные методы, включая конструкторы, геттеры/сеттеры свойств, методы добавления/удаления событий).
- F — количество полей экземпляра в классе.
- MF — это количество методов класса, обращающихся к определенному полю экземпляра.
- Sum(MF) — это сумма MF по всем полям экземпляра класса.
Основная идея, лежащая в основе этих формул, может быть сформулирована следующим образом: класс полностью связан, если все его методы используют все его поля экземпляра.
Я не уверен, насколько хорошо эта мера работает при работе с Java Bean, который вполне может иметь большое количество геттеров и сеттеров, каждый из которых имеет дело с одним свойством.
Имейте в виду, что числа, полученные различными инструментами для «одной и той же» метрики, сильно различаются. Иногда это происходит из-за того, что первоисточник был неточным, а иногда из-за того, что производитель инструментов «улучшил» метрику. Большинство метрических инструментов имеют пороговое значение по умолчанию. Я бы использовал это, если у вас нет веской причины не делать этого.
Я часто измеряю сплоченность в больших классах. Я не думаю, что когда-либо видел измерение LCOM-HS выше 1,0, но я думаю, что вы можете увидеть их для крошечных классов (где вы, вероятно, не очень заботитесь о сплоченности). Лично я использую порог 0,8, но это произвольно. Я читал много статей о сплоченности и видел очень мало упоминаний о пороговых значениях. Сюда входят документы Хендерсона-Селлерса, которые я читал.
djna прав, когда говорит, что меры связности дадут плохие оценки для JavaBeans и других классов "хранилища данных". Кроме того, многие измерения сплоченности, в том числе LCOM-HS, не учитывают некоторые вещи, которые могут привести к ошибочно низким оценкам. Например, многие реализации не учитывают связи с унаследованными элементами. LCOM-HS и многие другие также чрезмерно полагаются на то, как методы получают доступ к полям. Например, если вы напишете класс, в котором методы в основном взаимодействуют с «данными» через свои аргументы, вы получите то, что кажется крайне несвязанным классом; тогда как на самом деле он может быть хорошо спроектирован.
Что касается других показателей, которые вы упомянули, я не видел рекомендаций. Я осмотрелся, и единственная рекомендация, которую я видел в отношении количества методов XXX, - это максимум 20 на класс (без подробностей относительно экземпляра или статического, переопределенного и т. д.).
Здесь приведен список некоторых статей, посвященных метрикам объектно-ориентированного программирования, в основном сплоченность.
