Что такое Dependency Injection (DI)

Что проверяют

Отличаете ли вы принцип от библиотеки. Внедрение зависимостей это про архитектуру, контейнер это инструмент, и подмена одного другим слышна сразу.

Как отвечать

Dependency Injection это когда объект не создаёт свои зависимости сам, а получает их снаружи. Обычно через конструктор:

class OrderService {
  constructor(private readonly payments: PaymentGateway) {}
}

Что это даёт: класс зависит от абстракции, а не от конкретной реализации. В тесте вместо настоящей зависимости подставляется заглушка, в проде реализация меняется в одном месте, а по сигнатуре конструктора видно, от чего класс зависит вообще.

Способы внедрения: конструктор (по умолчанию, зависимость обязательна), свойство или сеттер (для необязательных), метод (когда нужна ровно в одном вызове).

На фронтенде отдельный контейнер нужен редко: зависимости передают параметрами или через контекст. В Angular и NestJS механизм встроен и собирает граф по типам, в React ту же роль играет контекст плюс свои хуки, которые прячут источник данных за интерфейсом.

Где спотыкаются

Считают, что DI это библиотека. Передать зависимость руками в конструктор это уже DI, контейнер лишь избавляет от сборки графа вручную.

Просят зависимость у контейнера прямо внутри метода. Это Service Locator, и по сигнатуре больше не видно, что классу нужно.

Внедряют конкретный класс вместо абстракции, после чего подменить его в тесте нечем.

Импортируют конкретный клиент прямо в компонент и потом не могут отрендерить его в тесте без сети.