Сколько Dagger компонентов может быть в приложении?

Количество компонентов Dagger в Android приложении

В приложении на основе Dagger 2 количество компонентов не имеет жестких ограничений и определяется архитектурными потребностями проекта. Однако существует ряд практических рекомендаций и типичных подходов к организации компонентов.

Типичные сценарии использования компонентов

1. Базовый подход с одним компонентом

Для простых приложений может использоваться единственный корневой компонент:

@Component(modules = [AppModule::class])
interface AppComponent {
    fun inject(activity: MainActivity)
    fun provideRepository(): DataRepository
}

2. Мультикомпонентная архитектура с зависимостью

Стандартный подход для средних и крупных проектов включает несколько компонентов с четкой иерархией:

• ApplicationComponent (корневой) — создается при запуске приложения, живет весь его цикл.
• ActivityComponent — для отдельных Activity, зависит от ApplicationComponent.
• FragmentComponent — для Fragment, зависит от ActivityComponent.
• ServiceComponent — для сервисов и других объектов с собственным жизненным циклом.

// Корневой компонент
@Component(modules = [NetworkModule::class, DatabaseModule::class])
interface ApplicationComponent {
    fun provideApiService(): ApiService
    fun provideDatabase(): AppDatabase
}

// Компонент для Activity с зависимостью
@Component(dependencies = [ApplicationComponent::class], 
           modules = [ActivityModule::class])
interface ActivityComponent {
    fun inject(activity: MainActivity)
}

3. Подкомпоненты (Subcomponents)

Альтернативный подход для управления зависимостями без явного указания dependencies:

@Component(modules = [AppModule::class])
interface AppComponent {
    fun activityComponent(): ActivityComponent.Builder
}

@Subcomponent(modules = [ActivityModule::class])
interface ActivityComponent {
    @Subcomponent.Builder
    interface Builder {
        fun build(): ActivityComponent
    }
    fun inject(fragment: MyFragment)
}

Критерии определения количества компонентов

1. Разделение ответственности — каждый компонент отвечает за инъекцию зависимостей в определенный scope (область видимости):

   • Singleton — глобальные объекты
   • ActivityScope — объекты, живущие во время жизни Activity
   • FragmentScope — объекты с жизненным циклом Fragment

2. Управление жизненным циклом — компоненты создаются и уничтожаются вместе с соответствующими Android компонентами:

   • Activity уничтожается → уничтожается ActivityComponent и все его зависимые объекты
   • Это помогает избежать утечек памяти и четко управлять ресурсами

3. Модульность и тестирование — отдельные компоненты позволяют:

   • Легко заменять модули в тестовых окружениях
   • Изолировать функциональные области приложения
   • Упрощать интеграцию новых функциональных модулей

Практические рекомендации

• Не создавайте чрезмерно много компонентов — каждый новый компонент добавляет сложность в управление зависимостями и может привести к ошибкам в иерархии.
• Следуйте принципу минимальной достаточности — создавайте компоненты только для логически отделенных областей с разными жизненными циклами.
• Используйте стандартные scope-аннотации или создавайте собственные для четкого определения жизненного цикла:

  @Scope
  @Retention(AnnotationRetention.RUNTIME)
  annotation class ActivityScope
  
  @Scope
  @Retention(AnnotationRetention.RUNTIME)
  annotation class FragmentScope
  

Пример реальной архитектуры

В типичном среднем приложении может быть:

1. AppComponent — Singleton scope, живет в Application
2. AuthComponent — для авторизации (может быть Subcomponent)
3. MainActivityComponent — Activity scope
4. DashboardFragmentComponent — Fragment scope, зависит от MainActivityComponent
5. SettingsFragmentComponent — отдельный Fragment scope
6. ServiceComponent — для background сервисов

Итого: количество компонентов обычно колеблется от 1 в маленьких приложениях до 10-15 в крупных проектах с сложной модульной структурой. Ключевой принцип — каждый компонент должен иметь четко определенную область ответственности и жизненный цикл, соответствующий бизнес-логике и архитектуре Android приложения.