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

Команда хочет протестировать свой OrderService. Тест создаёт один — и открывается реальное соединение с Postgres, срабатывает реальный вызов Stripe, и реальное письмо уходит на реальный адрес. Они не могут протестировать логику без всего продакшен-стека, потому что конструктор делает this.db = new PgClient(), this.payments = new StripeClient(), this.mail = new Mailer(). Логика никогда не была проблемой. Проблемой было связывание.

Связанность, создаваемая 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-контейнер автоматизирует эту сборку, но принцип держится и при ручном связывании: держи конструирование на краю, держи логику в середине свободной от зависимостей.