Почему предпочтительнее использовать Dependency Injection вместо создания объектов вручную

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

Умеете ли вы разрывать связь с синглтонами и писать код, который тестируется без сети и без экрана. Формулировка общая, но для iOS ответ ждут конкретный: протоколы, инициализаторы, окружение SwiftUI.

Как отвечать

Класс, который внутри себя дёргает URLSession.shared, UserDefaults.standard или собственный Manager.shared, тянет за собой сеть, диск и глобальное состояние. Тест такого класса ходит в сеть и зависит от порядка запусков. Инъекция означает, что зависимость приходит извне, а тип объявлен протоколом, а не конкретным классом.

Формы, которые стоит назвать:

• через инициализатор, когда объект создаёте вы: зависимости видны в сигнатуре и обязательны;
• через свойство для контроллеров из storyboard, куда параметры не передать, либо через фабрику или координатор, который собирает экран целиком;
• через окружение в SwiftUI: свой ключ окружения и подмена сверху, а в превью подставляется фейк, и экран рисуется без бэкенда.

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

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

Сводят ответ к контейнеру с регистрацией по типу. Разрешение в рантайме превращает забытую регистрацию в падение при открытии экрана, тогда как ручная сборка в одной точке проверяется компилятором.

Рассказывают по шаблону «ситуация, задача, действие, результат» с процентами ускорения. Это вопрос про архитектуру, от вас ждут границ и кода, а заученная схема выдаёт подготовку без опыта.

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