Использовали ли библиотеки для Dependency Injection
Что проверяют
Понимаете ли вы задачу и знаете ли, что в Swift она чаще решается языком, а не библиотекой.
Как отвечать
Смысл тот же: зависимости приходят снаружи, поэтому объект тестируем и не привязан к конкретной реализации.
В iOS способов несколько, и стоит показать, что вы понимаете их разницу:
- внедрение через конструктор без всяких библиотек. Самый прозрачный вариант, и в большинстве проектов его достаточно. Зависимости описываются протоколами, в тестах подставляются заглушки;
- контейнеры вроде Swinject: регистрация и разрешение по типу, области видимости. Удобно при большом графе, но ошибки вылезают в рантайме;
@EnvironmentиEnvironmentObjectв SwiftUI: встроенный способ прокинуть зависимость вниз по дереву без передачи через каждый уровень;- Factory и подобные современные библиотеки с проверкой на этапе компиляции и удобным подменом в тестах;
- композиция через фабрики и сборщики модулей в архитектурах вроде VIPER, где сборка экрана выделена явно.
Расскажите, как это выглядело у вас: кто создаёт зависимости на старте приложения, как передаются в экраны, как подменяются в тестах, есть ли отдельный слой сборки.
Если библиотек не использовали, это нормальный ответ: скажите, что обходились конструкторами и протоколами, и объясните почему. В Swift это часто осознанный выбор, а не пробел.
Где спотыкаются
Делают синглтоны вместо зависимостей и потом не могут написать тест.
Используют контейнер как глобальный доступ к сервисам из любого места, превращая его в тот же синглтон.
Не могут объяснить, зачем протокол, если реализация одна: ради подмены в тестах и границы между слоями.