Когда стоит использовать Provides в Dagger?

Когда использовать Provides в Dagger/Hilt

Provides — это аннотация в Dagger (и его более современной версии Hilt), которая используется для создания метода поставки в рамках модуля. Она указывает, что данный метод является источником конкретного типа зависимости для системы внедрения зависимостей (DI). Основная задача @Provides — предоставить Dagger способ создать объект, который не может быть сгенерирован автоматически через аннотацию @Inject.

Основные сценарии использования @Provides

1. Поставка объектов, которые не принадлежат вашей кодовой базе

Это самый распространенный и важный случай. Dagger может автоматически внедрять зависимости, создавая объекты, если их классы имеют конструктор с @Inject. Однако многие критически важные библиотеки (например, Retrofit, OkHttpClient, Room Database, SharedPreferences) являются внешними, и их конструкторы не аннотированы @Inject. Для их создания и предоставления в граф зависимостей необходимо использовать @Provides.

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton // Часто такие объекты создаются один раз
    fun provideOkHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .connectTimeout(30, TimeUnit.SECONDS)
            .readTimeout(30, TimeUnit.SECONDS)
            .build()
    }

    @Provides
    @Singleton
    fun provideRetrofit(client: OkHttpClient): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .client(client)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

В этом примере Dagger не знает, как создать OkHttpClient или Retrofit. Методы с @Provides становятся четкими инструкциями для него.

2. Поставка интерфейсов или абстрактных классов

Если зависимость представляет собой интерфейс или абстрактный класс, Dagger не может напрямую определить, какой конкретный класс (implementation) нужно использовать. Метод @Provides позволяет указать эту связь.

interface DataRepository {
    fun fetchData(): String
}

class RealRepository @Inject constructor() : DataRepository {
    override fun fetchData() = "Real Data"
}

@Module
@InstallIn(ActivityComponent::class)
object RepositoryModule {

    @Provides
    fun provideRepository(impl: RealRepository): DataRepository {
        // Здесь мы явно указываем, что для интерфейса DataRepository
        // нужно использовать конкретный объект RealRepository.
        return impl
    }
}

3. Конфигурация объектов с нестандартной логикой создания

Когда объект требует специальной логики при создании (например, условная инициализация, чтение из файла конфигурации, сложная сборка), метод @Provides предоставляет место для этой логики. Это гибкость, которую автоматическое внедрение не может обеспечить.

@Provides
@Singleton
fun provideDatabase(context: Application): AppDatabase {
    // Создание базы данных Room с возможностью кастомной конфигурации
    return Room.databaseBuilder(
        context,
        AppDatabase::class.java,
        "app_db"
    ).fallbackToDestructiveMigration() // Специальная логика
     .build()
}

4. Поставка разных реализаций в зависимости от условий (Qualifiers)

Иногда необходимо предоставлять разные объекты одного типа. Для этого используются qualifier-аннотации (например, @Named или свои собственные). Метод @Provides позволяет связать конкретный qualifier с конкретной реализацией.

@Qualifier
annotation class AuthHttpClient

@Qualifier
annotation class PublicHttpClient

@Module
object HttpClientModule {

    @Provides
    @AuthHttpClient
    fun provideAuthClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .addInterceptor(AuthInterceptor()) // Клиент с авторизацией
            .build()
    }

    @Provides
    @PublicHttpClient
    fun providePublicClient(): OkHttpClient {
        return OkHttpClient.Builder() // Клиент без авторизации
            .build()
    }
}

5. Поставка "примитивов" или строковых значений

Dagger не может сам создать такие значения как String, Int, Boolean, которые могут быть нужны для конфигурации (например, базовый URL API). Их источником также выступают методы @Provides.

@Module
object ConfigModule {

    @Provides
    @Named("BaseUrl")
    fun provideBaseUrl(): String {
        return BuildConfig.BASE_URL // Значение может браться из конфигурации
    }
}

Когда НЕ стоит использовать Provides

Чтобы решение было правильным, важно также понимать противоположные случаи:

• Если класс принадлежит вашей кодовой базе и имеет конструктор с @Inject. В этом случае Dagger справится самостоятельно, и создавать @Provides метод будет излишним дублированием.
• Для простых внедрений @Inject полей. Использование @Provides для объектов, которые уже могут быть внедрены автоматически, добавляет ненужную сложность и нарушает принцип "чем меньше кода модуля, тем лучше".

Принципиальная разница между @Provides и @Binds

В современных Dagger/Hilt для поставки интерфейсов часто используют аннотацию @Binds вместо @Provides, когда логика создания сводится просто к возврату уже существующего объекта (как в примере с DataRepository выше).

• @Provides — это метод, который выполняет код для создания объекта.
• @Binds — это абстрактный метод или метод в абстрактном модуле, который лишь указывает связь (тип -> реализация), не выполняя код. Он более эффективен и рекомендуется, когда не требуется сложной логики создания.

Итог и ключевые выводы

@Provides является фундаментальным инструментом в Dagger для ситуаций, когда автоматическое внедрение невозможно или недостаточно. Его основное предназначение:

1. Предоставление внешних зависимостей (Retrofit, OkHttp, Room, etc.).
2. Реализация связывания для абстрактных типов (интерфейсов).
3. Конфигурация объектов с нестандартной или сложной логикой инициализации.
4. Разделение поставки однотипных объектов через qualifiers.

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