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

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

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

Как отвечать

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

final class OrderService {
    private let payments: PaymentGateway
    init(payments: PaymentGateway) { self.payments = payments }
}

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

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

В iOS зависимость обычно описывают протоколом, а подставляют через инициализатор. Синглтоны вроде URLSession.shared внутри класса это та же жёсткая связь: в тесте её нечем заменить, поэтому сетевой слой прячут за протоколом.

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

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

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

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

Обращаются к .shared прямо в методе и потом не могут написать тест без сети.