Cohesion

Спектр cohesion

Yourdon и Constantine определили cohesion по спектру от случайной (самая слабая) до функциональной (самая сильная), как они определили лестницу coupling. Уровни описывают, почему элементы модуля сгруппированы вместе.

Coincidental cohesion (самая слабая): элементы сгруппированы без структурной причины — они случайно оказались в одном файле или классе. BillingUtils из открытой истории — пример случайной cohesion. Единственное, что связывает её функции — разработчик решил там их разместить. Любой рефакторинг требует чтения всего модуля, чтобы понять, что в нём есть.

Logical cohesion: элементы сгруппированы, потому что логически похожи — все обработчики ошибок, все форматтеры строк, все функции валидации. Класс StringUtils с trim, truncate, toSlug и escapeHtml имеет логическую cohesion. Они разделяют общую область (строки), но не обязательно изменяются вместе или служат одной цели.

Temporal cohesion: элементы сгруппированы, потому что выполняются в одно время — вся логика инициализации при запуске, вся логика очистки при завершении. Функции выполняются вместе, но могут не иметь ничего общего в остальном.

Communicational cohesion: элементы сгруппированы, потому что работают с одними данными. Все функции, работающие с объектом Order, образуют communicationally cohesive группу — но единый класс Order с десятками методов для совершенно разных задач (pricing, shipping, fulfillment, billing, audit) по-прежнему слабо cohesive, если эти задачи изменяются по несвязанным причинам.

Functional cohesion (самая сильная): все элементы вносят вклад в единую, чётко определённую цель. Модуль делает одно дело, все его части служат этому одному делу, и изменение этого одного дела требует изменения только этого модуля. InvoiceGenerator, принимающий подтверждённый заказ и создающий отформатированный инвойс с корректным налогом и итогами — и больше ничего — имеет функциональную cohesion. Когда формат инвойса изменяется — изменяешь этот модуль. Когда меняется налоговое законодательство — изменяешь расчёт налогов в этом модуле. Когда меняется статус платежа — этот модуль не трогаешь.

LCOM: структурная интуиция для cohesion

Lack of Cohesion of Methods (LCOM) — статическая метрика, дающая структурное ощущение того, насколько хорошо методы класса принадлежат вместе. Интуиция проста: если класс имеет методы A, B и C, и методы A и B разделяют поля экземпляра, а метод C не разделяет ни одного поля ни с одним из них — класс, вероятно, делает два дела. Метод C, скорее всего, принадлежит в другое место.

Наиболее полезная форма (LCOM4 или вариант в обычных инструментах статического анализа) считает количество связных компонентов в графе, где узлы — методы, а рёбра соединяют методы, разделяющие хотя бы одно поле экземпляра. LCOM = 1 — идеал: каждый метод достижим от каждого другого через общие поля — весь класс одна тесно связная вещь. LCOM > 1 означает, что класс имеет несколько независимых кластеров, которые, вероятно, должны быть отдельными модулями.

В B2B-платформе представь класс BillingProcessor с такими связями метод/поле:

• generateInvoice() и calculateTax() оба используют orderItems и customerId
• sendEmailNotification() и formatEmailBody() оба используют emailAddress и emailTemplate
• Ни один метод первой группы не разделяет ни одного поля со второй группой

LCOM = 2. Класс делает две несвязанные вещи: генерацию инвойсов и отправку email. Это должны быть два класса.

Cohesion как противовес избыточному decoupling

Предыдущий урок установил, что coupling следует минимизировать — конкретно, степень, в которой один модуль зависит от внутренностей другого. Но в крайности «минимизировать coupling» производит модули настолько мелкозернистые, что ни один модуль не имеет собственного содержания. Пятьдесят классов, каждый с одним методом. Каждая операция требует компоновки пятнадцати классов. У кода data coupling везде и он полностью нечитаем.

Cohesion — противодействующая сила. Высоко cohesive модуль держит вместе то, что изменяется вместе — что точно и определяет хорошую структурную границу. Когда всё в модуле изменяется по одной причине, модуль — стабильная единица эволюции. Когда части модуля изменяются по разным причинам, модуль — неправильная граница.

Практическая связь: высокая cohesion естественно снижает coupling-поверхность. Высоко cohesive InvoiceGenerator предоставляет чистый, минимальный интерфейс (data coupling снаружи), потому что всё, что ему нужно внутренне, уже инкапсулировано. Тебе не нужно заглядывать в его внутренности, потому что все его внутренности скоординированы на одну цель. Низкая cohesion, напротив, вынуждает вызывающих знать о внутренней структуре модуля — потому что модулю не на что опереться.