Как Dagger строит граф зависимостей
Что проверяют
Понимаете ли вы, что граф собирается на этапе компиляции, и знаете ли, из чего он строится.
Как отвечать
Dagger это обработчик аннотаций: во время сборки он анализирует объявления и генерирует код, который создаёт объекты в нужном порядке. Никакой рефлексии в рантайме нет.
Из чего складывается граф:
@Injectна конструкторе говорит, что Dagger умеет создать этот тип сам, а параметры конструктора становятся его зависимостями. Это основной способ;@Moduleс методами@Providesнужны для типов, конструктор которых недоступен: чужие библиотеки, интерфейсы, объекты со сложной сборкой;@Bindsсвязывает интерфейс с реализацией дешевле, чем@Provides, потому что не порождает тела метода;@Componentэто точка входа: в нём перечислены модули и объявлены методы получения объектов. Именно для компонента генерируется реализация;- области видимости (
@Singletonи собственные) определяют, будет ли объект один на компонент или создаваться заново; @Qualifierразличает несколько реализаций одного типа;Provider<T>иLazy<T>откладывают создание, а@Subcomponentи компоненты с зависимостями образуют иерархию областей.
Главное преимущество, которое стоит назвать: если зависимости не хватает или она объявлена дважды, это ошибка компиляции с указанием места, а не падение в рантайме. Цена это время сборки и порог входа.
В Android поверх этого работает Hilt: он предоставляет готовые компоненты под приложение, активити, фрагмент и ViewModel, избавляя от ручного описания иерархии.
Где спотыкаются
Не могут объяснить разницу между @Provides и @Binds.
Кладут всё в область приложения и получают объекты, живущие дольше нужного.
Считают, что Dagger работает через рефлексию, как контейнеры в Spring.