Из каких элементов состоит Dagger

Dagger — это статически типизированный фреймворк для внедрения зависимостей (DI), который генерирует код во время компиляции, обеспечивая высокую производительность и раннее обнаружение ошибок. Его архитектура состоит из нескольких ключевых элементов, которые взаимодействуют для предоставления зависимостей в приложении. Вот основные компоненты:

Основные элементы Dagger

1. Модули (Modules)

Это классы, помеченные аннотацией @Module. Их задача — предоставлять зависимости, которые Dagger не может создать сам (например, объекты сторонних библиотек, экземпляры, требующие сложной логики инициализации). Внутри модулей определяются методы с аннотацией @Provides или @Binds.

• @Provides методы — возвращают экземпляр зависимости. Здесь можно описать логику создания объекта.

  @Module
  object NetworkModule {
      @Provides
      fun provideOkHttpClient(): OkHttpClient {
          return OkHttpClient.Builder()
              .connectTimeout(30, TimeUnit.SECONDS)
              .build()
      }
  
      @Provides
      fun provideRetrofit(client: OkHttpClient): Retrofit {
          return Retrofit.Builder()
              .baseUrl("https://api.example.com/")
              .client(client)
              .build()
      }
  }
  

• @Binds методы — это абстрактные методы в абстрактном классе или интерфейсе модуля. Они указывают Dagger, какую реализацию использовать для абстрактного типа (например, интерфейса). Это более эффективно, чем @Provides, так как не требует написания тела метода.

  @Module
  abstract class RepositoryModule {
      @Binds
      abstract fun bindUserRepository(impl: UserRepositoryImpl): UserRepository
  }
  

2. Компоненты (Components)

Это интерфейсы или абстрактные классы, помеченные аннотацией @Component. Они являются ядром Dagger, выступая в роли моста между модулями (поставщиками зависимостей) и классами, которые эти зависимости запрашивают (потребителями). Компонент отвечает за:

• Создание графа зависимостей (объектной модели, описывающей, какие объекты нужны другим).
• Определение точек внедрения (куда можно "вставить" зависимости).
• Управление жизненным циклом определенных зависимостей (если используется @Scope).

Через аргумент modules компоненту указывается, какие модули он должен использовать.

@Component(modules = [NetworkModule::class, RepositoryModule::class])
interface ApplicationComponent {
    // Фабричный метод для создания самого компонента (часто через Builder)
    // fun create(): ApplicationComponent

    // Методы внедрения. Dagger сгенерирует класс, который реализует этот интерфейс.
    fun inject(activity: MainActivity)

    // Предоставление зависимостей для доступа извне (например, для другой Activity)
    fun getRetrofit(): Retrofit
}

Dagger на основе этого интерфейса генерирует класс с префиксом Dagger (например, DaggerApplicationComponent), который является реализацией компонента.

3. Области видимости (Scopes)

Аннотации, такие как @Singleton, которые управляют жизненным циклом экземпляра зависимости в рамках определенного контекста. Они указывают, будет ли создан новый экземпляр при каждом запросе или будет переиспользован существующий.

• @Singleton — наиболее известная область. Объект создается один раз на весь жизненный цикл компонента.

  @Singleton
  @Provides
  fun provideSharedPrefs(app: Application): SharedPreferences {
      return app.getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
  }
  

• Пользовательские области (например, @ActivityScope, @FragmentScope) могут быть созданы для привязки жизни зависимости к жизни Activity или Fragment. Для этого используется аннотация @Scope.

4. Граф зависимостей (Dependency Graph)

Это внутренняя структура, которую Dagger строит и которой управляет на основе предоставленных модулей и компонентов. Она представляет собой направленный ациклический граф (DAG), где узлы — это зависимости, а ребра — это отношения "предоставляет/зависит от". Dagger анализирует этот граф во время компиляции, проверяет его полноту (все зависимости можно разрешить) и отсутствие циклов, а затем генерирует код, который эффективно создает и предоставляет все необходимые объекты.

5. Внедрение зависимостей (Dependency Injection)

Способ получения зависимостей от компонента в целевые классы (Activity, Fragment, ViewModel и др.). Существует три основных способа:

• Внедрение через конструктор (Constructor Injection): Самый предпочтительный и тестируемый способ. Аннотация @Inject ставится прямо над конструктором класса. Dagger сможет создать экземпляр такого класса самостоятельно.

  class UserRepositoryImpl @Inject constructor(
      private val apiService: ApiService
  ) : UserRepository { ... }
  

• Внедрение через поля (Field Injection): Используется для классов, инстанцирование которых Dagger не контролирует (например, Android Activity, создаваемые системой). Аннотация @Inject ставится над полем класса, а затем в методе жизненного цикла (например, onCreate) вызывается метод inject() компонента.

  class MainActivity : AppCompatActivity() {
      @Inject
      lateinit var viewModelFactory: ViewModelProvider.Factory
  
      override fun onCreate(savedInstanceState: Bundle?) {
          // Внедрение должно произойти ДО super.onCreate() для Fragment-совместимости
          (application as MyApp).appComponent.inject(this)
          super.onCreate(savedInstanceState)
          // Теперь viewModelFactory инициализирована и готова к использованию
      }
  }
  

• Внедрение через методы (Method Injection): Наименее распространенный способ, когда @Inject ставится над методом, и зависимости передаются в качестве его параметров. Dagger вызовет этот метод после создания экземпляра класса.

Сопутствующие элементы (Dagger 2)

• Subcomponents (Подавтомобили): Компоненты, которые наследуют граф зависимостей от родительского компонента и могут расширять его своими модулями. Часто используются для изоляции зависимостей, связанных с жизненным циклом экрана (Activity/Fragment).
• Component Dependencies: Альтернативный способ организации иерархии компонентов, где один компонент явно объявляет зависимость от другого, получая доступ только к тем зависимостям, которые явно предоставлены через интерфейс.
• @BindsInstance: Позволяет передать в компонент зависимость, которая уже существует на момент создания графа (например, экземпляр Context или Application). Используется в Builder компонента.

  @Component.Builder
  interface Builder {
      @BindsInstance
      fun application(application: Application): Builder
      fun build(): ApplicationComponent
  }
  // Использование:
  // val component = DaggerApplicationComponent.builder()
  //     .application(this)
  //     .build()
  

Процесс работы вкратце

1. Компиляция: Dagger Annotation Processor (APT) сканирует код с аннотациями @Module, @Component, @Inject и т.д.
2. Анализ и проверка: Строится граф зависимостей и проверяется на корректность.
3. Генерация кода: Создаются конкретные классы-реализации компонентов (например, DaggerApplicationComponent), которые содержат весь код для создания и предоставления зависимостей.
4. Выполнение: Во время выполнения приложение использует сгенерированные классы для получения экземпляров зависимостей. Внедрение происходит быстро, так как вся "тяжелая" работа была сделана на этапе компиляции.

Таким образом, взаимодействие Модулей, Компонентов и правильное использование Областей видимости позволяет Dagger создавать предсказуемый, хорошо структурированный и эффективный механизм управления зависимостями в приложении.