Внедрение зависимостей в мобильном приложении
Вопрос
Как вы организуете DI в приложении? Ручной DI или фреймворк?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Внедрение через конструктор, зависимости по интерфейсам
Composition root и сборка графа в одном месте
Скоупы: приложение, сессия пользователя, экран
Фреймворк по размеру проекта: проверка при компиляции против простоты
Тесты с фейками и проверка графа
Не превращать контейнер в глобальный локатор
Что могут спросить следом
- Как вы тестируете, что граф собирается?
- Что делать с объектами, которые создаёт система?
Разбор
Базовый принцип: зависимости приходят через конструктор и описаны интерфейсами. Тогда класс честно показывает, что ему нужно, а в тестах я подставляю фейки. Граф собирается в одном месте у входа в приложение, а фичевые модули предоставляют свои фабрики. Важны скоупы: сетевой клиент живёт всё время, пользовательские репозитории в скоупе сессии и уничтожаются при выходе, view model на экран. Инструмент выбираю по размеру проекта. На Android в больших проектах Hilt: ошибки графа ловятся при сборке. В небольших Koin, но с тестом проверки графа. На iOS чаще ручной DI с фабриками, иногда контейнер. Главное не давать вызывать контейнер из любого места: тогда DI превращается в локатор со всеми его минусами.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.