Что такое внедрение зависимостей

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

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

Как отвечать

Суть: объект не создаёт свои зависимости, а получает их снаружи, через конструктор, реже через поле или метод. Класс перестаёт знать, откуда берётся репозиторий, и зависит от абстракции.

Специфика платформы важнее определения. Экранные компоненты инстанцирует система, конструктор с параметрами туда не передать, поэтому зависимости приходят в поля, а вся содержательная логика уезжает во вью-модели и репозитории, которые уже принимают зависимости конструктором.

Про инструменты стоит говорить сравнением. Dagger и надстройка Hilt собирают граф на этапе компиляции: неверно описанная зависимость ломает сборку, а не приложение на устройстве, плюс есть готовые области жизни для приложения, экрана и вью-модели. Koin работает в рантайме, описание короче, но ошибку графа вы увидите позже и по сути получаете сервис-локатор. Для небольшого проекта честный ручной граф в классе приложения тоже нормальный ответ.

Полезно отдельно проговорить области жизни: синглтон живёт с процессом, состояние экрана должно переживать поворот и умирать вместе с уходом с экрана. Именно здесь ошибки стоят дороже всего.

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

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

Передают контекст экрана в объект, который живёт дольше экрана, и удерживают уничтоженный компонент. Это классическая утечка памяти: долгоживущим зависимостям нужен контекст приложения.

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