Метрики кода — связь классов

Классовая связь также известна под названием Связь между объектами (CBO), как изначально определено в CK94. В основном связь классов — это мера того, сколько классов использует один класс. Большое число плохо, и низкое число обычно хорошо с этой метрикой. Связь классов показала себя как точный предиктор отказов программного обеспечения, и последние исследования показали, что верхний предел в 9 является наиболее эффективным S2010.

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

Концепции связывания и сплоченности четко связаны. Чтобы сохранить эту дискуссию по теме, мы не будем углубляться в тему связности, кроме другого, чем дать краткое определение из KKLS2000:

Когезия модуля была введена Yourdon и Constantine как мера того, насколько тесно связаны внутренние элементы модуля друг с другом YC79. Модуль имеет сильную сплоченность, если она представляет ровно одну задачу [...], и все его элементы способствуют этой одной задаче. Они описывают сплоченность как атрибут дизайна, а не код, а атрибут, который можно использовать для прогнозирования повторного использования, удобства обслуживания и изменчивости».

Пример зависимости классов

Рассмотрим связь классов в действии. Сначала создайте консольное приложение и создайте класс Person с некоторыми свойствами в нем, а затем сразу вычислите метрики кода:

Обратите внимание, что связь классов имеет значение 0, так как этот класс не использует другие классы. Теперь создайте другой класс PersonStuff с методом, который создает экземпляр Person и задает значения свойств. Вычислите метрики кода еще раз:

Увидели, как увеличивается значение связи классов? Обратите внимание, что независимо от того, сколько свойств задано, значение зависимостей класса просто поднимается на 1, а не на какое-то другое значение. Классовая связность измеряет каждый класс только один раз для этой метрики, независимо от частоты его использования. Кроме того, можно увидеть, что у DoSomething() значение 1, а конструктор PersonStuff() имеет значение 0. В настоящее время в конструкторе отсутствует код, использующий другой класс.

Что делать, если вы помещаете код в конструктор, который использовал другой класс? Вот что вы получаете:

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

Затем создайте другой класс. Присвойте этому классу имя и создайте в нем некоторые свойства:

Теперь используйте класс в методе DoSomething() внутри класса PersonStuff и снова вычисляйте метрики кода.

Как видно, связь классов для класса PersonStuff достигает 2, и, если вы проведете анализ класса, можно увидеть, что метод DoSomething() имеет наибольшее количество связей, но конструктор по-прежнему потребляет только 1 класс. Используя эти метрики, вы можете увидеть общее максимальное число для данного класса и углубиться в детали для каждого члена отдельно.

Магическое число

Как и в случае с цикломатической сложностью, нет ограничений, которые соответствуют всем организациям. Однако S2010 указывает, что предел 9 является оптимальным:

Поэтому мы считаем пороговые значения [...] наиболее эффективными. Эти пороговые значения (для одного члена) — CBO = 9[...]". (акцент добавлен)

Анализ кода

Анализ кода включает категорию правил обслуживания. Дополнительные сведения см. в правилах обслуживания. При использовании устаревшего анализа кода набор правил расширенного руководства по проектированию содержит область обслуживания:

В области поддерживаемости существует правило для когезии классов:

Это правило выдает предупреждение при чрезмерной связанности классов. Дополнительные сведения см. в разделе CA1506: избегайте чрезмерного связывания классов.

Цитаты

CK94

Chidamber, S. R. и Kemerer, C. F. (1994). Набор метрик для объектно-ориентированного проектирования (ТРАНЗАКЦИИ IEEE по программному проектированию, vol. 20, No 6). Получено 14 мая 2011 года из веб-сайта Университета Питтсбурга: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., and Saint-Denis, G. (2000). Сплоченность класса пересмотрена: эмпирическое исследование промышленных систем (труды семинара по количественным подходам в объектно-ориентированной программной инженерии). Получено 20 мая 2011 г. из веб-сайта Université de Montréal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Субрамам, Р. и Шрина, М. С. (2003). Эмпирический анализ метрик CK для сложности объектно-ориентированного проектирования: последствия для дефектов программного обеспечения (IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Шатнави, Р. (2010). Количественное исследование допустимых уровней риска метрик объектно-ориентированных в системах с открытым исходным кодом (IEEE Transactions по разработке программного обеспечения, т. 36, № 2).

YC79

Эдвард Твойдон и Ларри Л. Константин. Структурированный дизайн. Prentice Hall, Englewood Cliffs, N.J., 1979.