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

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

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

Как отвечать

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

type OrderService struct{ payments PaymentGateway }

func NewOrderService(p PaymentGateway) *OrderService { return &OrderService{payments: p} }

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

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

В Go контейнеры почти не используют: граф собирают руками в main, а зависимость описывают интерфейсом на стороне потребителя, а не поставщика. Из инструментов встречается wire, который генерирует ту же ручную сборку кодом на этапе компиляции.

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

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

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

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

Объявляют интерфейс рядом с реализацией вместо места использования, из-за чего он обрастает методами, ненужными ни одному потребителю.