Метрики кода — связь классов
Связь между объектами (CBO) также определяется именем CK94. В основном связь классов — это мера того, сколько классов использует один класс. Большое число плохо, и низкое число обычно хорошо с этой метрикой. Связь классов показана как точный прогнозор сбоя программного обеспечения и последние исследования показали, что максимальное значение 9 является наиболее эффективным S2010.
Согласно документации Майкрософт, объединение классов "измеряет связь с уникальными классами с помощью параметров, локальных переменных, возвращаемых типов, вызовов методов, универсальных или шаблонных экземпляров, базовых классов, реализаций интерфейса, полей, определенных во внешних типах и оформлении атрибутов. Хороший дизайн программного обеспечения диктует, что типы и методы должны иметь высокую сплоченность и низкую связь. Высокая связь означает дизайн, который трудно использовать и поддерживать из-за его многочисленных взаимозависимостей по другим типам".
Концепции связывания и сплоченности четко связаны. Чтобы сохранить эту дискуссию по теме, мы не будем проникать в глубину с сплоченностью, кроме того, чтобы дать краткое определение из KKLS2000:
"Согласованность модуля была введена Yourdon и Константин как "как тесно привязаны или связаны внутренние элементы модуля друг к другу" 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 в области программного обеспечения, vol. 29, No 4).
S2010
Шатнави, Р. (2010). Количественное исследование допустимых уровней рисков объектно-ориентированных метрик в системах с открытым исходным кодом (транзакции IEEE по программному проектированию, vol. 36, No 2).
YC79
Эдвард Твойдон и Ларри Л. Константин. Структурированный дизайн. Prentice Hall, Englewood Cliffs, N.J., 1979.