Инверсия управления: как зависимости добираются до класса

Связанность, создаваемая new

Когда класс пишет new EmailService() внутри себя, он принял необратимое решение за каждого вызывающего: этот код есть реальный email-сервис, всегда. Нельзя подставить фейк в тесте, подменить другую реализацию на окружение или переиспользовать класс с другим коллаборатором. Зависимость скрыта (невидима в типе) и жёсткая (приварена при конструировании).

Инверсия управления

Инверсия управления (IoC) переворачивает, кто решает. Вместо того чтобы класс выбирал конкретного коллаборатора, класс объявляет абстрактную потребность, а что-то другое поставляет конкретного. Внедрение зависимостей — самая частая форма IoC: зависимости внедряются снаружи, а не конструируются внутри.

Чистейшее внедрение — через конструктор:

class OrderService {
  constructor(
    private db: Database,
    private payments: PaymentGateway,
    private mail: Mailer,
  ) {}
}

Теперь сигнатура конструктора — честный, проверяемый на компиляции список всего, что нужно классу. Тест передаёт фейки; продакшен передаёт реальные. Зависимость стала видимой и мягкой.

Service locator: соблазнительный кузен внедрения

Service locator (локатор служб — глобальный реестр, у которого класс запрашивает свои зависимости) тоже избегает new, но класс просит зависимости у этого реестра: const db = Container.get('Database'). Это выглядит как DI, но возвращает первородный грех — зависимости снова скрыты (конструктор больше их не перечисляет), и класс связан с локатором. Это широко считается антипаттерном в прикладном коде именно потому, что скрывает, что нужно классу, и падает лишь в рантайме, не на компиляции и не на старте.

Корень композиции

Спроси себя: если ни один класс не конструирует свои зависимости сам, кто это делает? Именно на этот вопрос отвечает корень композиции. Если классы больше не конструируют свои зависимости, что-то должно. Это что-то — корень композиции: единственное место рядом с точкой входа приложения, где собирается весь граф объектов — единственное место, называющее конкретные реализации. Всё ниже зависит лишь от абстракций. Централизация конструирования означает, что есть ровно одна точка для смены связывания, подмены реализаций или считывания всего графа зависимостей. DI-контейнер автоматизирует эту сборку, но принцип держится и при ручном связывании: держи конструирование на краю, держи логику в середине свободной от зависимостей.

Компромисс здесь — магия против явности. Контейнер покупает вам слабую связанность и тестовый шов в одну строку, но платит за это стоимостью старта и отлаживаемостью. Контейнеры на рефлексии и декораторах вынуждены читать метаданные, чтобы понять, что внедрять: приложение NestJS с несколькими сотнями провайдеров обычно тратит десятки-сотни миллисекунд на сборку графа при загрузке, и эта рефлексия метаданных — заметная доля холодного старта, из-за чего она и жжёт в serverless-функции, оплачиваемой помиллисекундно и вызываемой вхолодную. Ручное связывание — противоположность: корень композиции из обычных вызовов new в одном файле разрешается за микросекунды, каждая зависимость видна для «перейти к определению», а стек-трейс идёт через ваш код, а не через внутренности разрешения фреймворка. Ход сеньора — отказаться от контейнера, когда граф мал. Для CLI, воркера или узкоспециализированной Lambda с пятью объектами одна фабричная функция — buildApp(), которая new-ает эти пять и возвращает корень, — стартует быстрее, легче отлаживается и строго честнее, чем декораторы и контейнер ради сборки пяти объектов.

Все три подхода различаются по одному измерению: когда ты обнаруживаешь неверное связывание. Скрытый new — значит никогда, ты несёшь неверную зависимость вечно. Service locator — значит в рантайме, глубоко в запросе. Внедрение через конструктор — значит на старте или компиляции, до того как хоть один пользователь пострадает.