Имейте в виду, что числа, производимые различными инструментами для «одной и той же» метрики, сильно различаются.Иногда это происходит из-за того, что исходный источник был неточным, а иногда из-за того, что производитель инструментов «улучшил» метрику.Большинство метрических инструментов имеют порог по умолчанию.Я бы использовал это, если у вас нет веских причин не делать этого.
Я делаю много измерений когезии для больших классов.Я не думаю, что когда-либо видел измерения LCOM-HS выше 1,0, но я думаю, что вы можете увидеть их для крошечных классов (где вы, вероятно, не особо заботитесь о связности).Лично я использую порог 0,8, но это произвольно.Я прочитал много статей о сплоченности и видел очень мало упомянутых порогов.Это включает в себя статьи Хендерсона-Селлерса, которые я прочитал.
djna является правильным, когда он говорит, что меры сплоченности дадут плохие оценки для JavaBeans и других классов «хранения данных».Кроме того, многие измерения когезии, в том числе LCOM-HS, не учитывают некоторые вещи, которые могут привести к ошибочно плохим оценкам.Например, многие реализации не рассматривают отношения с унаследованными членами.LCOM-HS и многие другие также имеют чрезмерную зависимость от методов доступа к полям.Например, если вы напишите класс, в котором методы в основном взаимодействуют с «данными» через свои аргументы, вы получите то, что выглядит как весьма несвязный класс;тогда как в действительности он может быть хорошо спроектирован.
Что касается других упомянутых вами показателей, я не видел рекомендаций.Я осмотрелся, и единственная рекомендация, которую я видел относительно количества методов XXX, - максимум 20 на класс (никаких подробностей относительно экземпляра, статического, переопределенного и т. Д.).
Здесь - список некоторых работ, посвященных ОО-метрикам, главным образом связности.