Интерфейс объявлен отдельно от реализации, но модуль всё равно трудно менять независимо. Какой механизм создаёт эту связанность?
Само наличие интерфейса не устраняет связанность: она сохраняется, если интерфейс отражает детали реализации или его изменения требуют синхронного изменения зависимого модуля. Слабая связанность возникает тогда, когда граница описывает устойчивую потребность потребителя, а не внутреннее устройство поставщика.
Абстракции появились как средство отделить использование компонента от знания о его реализации. Это решало проблему каскадных изменений: замена структуры данных или алгоритма не должна была заставлять переписывать весь код, который с ними работает.
Позднее этот подход стал частью принципов модульности, инверсии зависимостей и архитектур портов и адаптеров. Однако практика показала, что формальный интерфейс может лишь скрыть прямую ссылку на класс, сохранив ту же семантическую зависимость.
Модуль может зависеть не от конкретного класса, а от интерфейса, который содержит методы, типы данных и правила, характерные только для одной реализации. Тогда реализацию формально можно заменить, но практически любое изменение её модели или сценариев использования затрагивает потребителя.
Особенно опасны интерфейсы, которые:
В результате граница становится номинальной. Компиляция может подтверждать соблюдение интерфейса, но не гарантирует независимую эволюцию модулей.
Нужно отделять синтаксическую зависимость от семантической. Синтаксическая зависимость означает, что потребитель знает имя интерфейса и его операции. Семантическая возникает, когда потребитель знает внутренние правила, структуру данных, порядок действий или неявные ограничения поставщика.
Чтобы уменьшить связанность, интерфейс следует проектировать со стороны потребителя. Он должен выражать минимальную потребность конкретного сценария, использовать устойчивые бизнес-понятия и скрывать технические детали реализации. Поставщик затем преобразует этот контракт во внутренние вызовы и модели.
Полезно проверить несколько свойств:
Инверсия зависимостей помогает определить направление связи, но не делает любой интерфейс хорошей границей автоматически. Если интерфейс владеет деталями базы данных, сетевого протокола или конкретной доменной модели поставщика, зависимость просто перемещается с класса на плохо выбранную абстракцию.
Компромисс состоит в том, что слишком узкие интерфейсы могут привести к повторяющимся адаптерам и дополнительным преобразованиям данных. Это приемлемая цена, если преобразования защищают модуль от нестабильной модели другой подсистемы; но чрезмерное дублирование контрактов также нужно контролировать.
Модуль расчёта тарифов предоставлял интерфейс, возвращающий объект внутренней модели тарифа. Потребитель использовал поля этого объекта, знал специальные статусы расчёта и зависел от порядка вызова нескольких методов. После изменения алгоритма и структуры тарифа пришлось обновлять несколько потребителей, хотя формально они зависели только от интерфейса.
Рассматривались два варианта. Первый — сохранить общий интерфейс и добавлять в него новые методы: это требовало меньше начальных изменений, но постепенно увеличивало связанность и превращало интерфейс в отражение реализации. Второй — определить отдельные операции под конкретные сценарии потребителей и возвращать стабильные результаты без внутренних типов: это увеличивало объём адаптеров, зато изолировало изменения.
Выбрали второй вариант. Контракт стал описывать необходимые бизнес-операции и результаты, а преобразование внутренней модели выполнялось внутри модуля тарифов. В итоге изменение алгоритма и структуры хранения перестало требовать изменений потребителей, пока сохранялась их бизнес-потребность.
Нет. Если интерфейс экспортирует внутренние типы, технические ошибки или предполагает конкретный порядок вызовов, потребитель всё ещё зависит от реализации семантически. Абстракция полезна только тогда, когда она стабилизирует контракт и скрывает причины изменений поставщика.
Универсального правила для всех случаев нет, но для границы между независимыми модулями интерфейс обычно полезно формировать вокруг потребностей потребителя. Это предотвращает публикацию лишних возможностей поставщика и позволяет каждому сценарию иметь минимальный контракт. Внутри одного тесно связанного компонента интерфейс, принадлежащий поставщику, также может быть разумным — например, если он представляет его стабильную публичную возможность.
Потому что связанность определяется не только набором операций, но и смыслом их поведения. Реализация, которая соблюдает небольшой контракт с независимыми результатами, заменяется легко. Другая реализация может требовать транзакционности, особого порядка вызовов, конкретной модели ошибок или ограничения по времени — тогда потребитель фактически зависит от дополнительных неявных условий, не выраженных интерфейсом.