В чем разница между аннотацией Provides и Binds?

Разница между аннотациями @Provides и @Binds в Dagger 2

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

Аннотация @Provides

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

@Module
class NetworkModule {

    @Provides
    fun provideOkHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .connectTimeout(10, TimeUnit.SECONDS)
            .build()
    }

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

Ключевые характеристики @Provides:

• Метод должен возвращать конкретный тип зависимости.
• Он может содержать любой код для создания объекта (конструкторы, фабричные методы, конфигурацию).
• Может принимать другие зависимости как параметры (как client для Retrofit выше).
• Подходит для предоставления:

    *   Объектов, создаваемых с помощью сложной логики (конфигурация, Builder).
    *   Зависимости из сторонних библиотек, где Dagger не может вызвать конструктор напрямую.
    *   Конкретных реализаций, когда интерфейс не используется.

Аннотация @Binds

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

@Module
abstract class RepositoryModule {

    @Binds
    abstract fun bindUserRepository(impl: UserRepositoryImpl): UserRepository
}

Ключевые характеристики @Binds:

• Метод должен быть абстрактным.
• Он принимает конкретную реализацию как параметр и возвращает абстрактный тип (интерфейс или абстрактный класс).
• Не содержит тела метода (не создает объекты).
• Компилятор Dagger генерирует более эффективный код, так как не нужен вызов метода @Provides.
• Подходит для предоставления:

    *   Реализаций интерфейсов или абстрактных классов.
    *   Ситуаций, где зависимость уже создана (например, через `@Inject` конструктор или другой `@Provides` метод).

Основные различия и выбор между ними

Когда использовать @Provides:

• Когда объект нужно создать с помощью специального кода (например, Retrofit.Builder()).
• Когда предоставляется зависимость из библиотеки, у которой нет @Inject конструктора.
• Когда нужно создать синглтон с сложной логикой инициализации.
• Для предоставления значений типа String, Int, Boolean и других "простых" типов.

Когда использовать @Binds:

• Когда нужно связать интерфейс с его конкретной реализацией (классический случай для паттерна Dependency Injection).
• Когда конкретная реализация уже может быть создана Dagger (через @Inject конструктор или другой модуль).
• Для оптимизации: Если есть выбор между @Provides и @Binds для интерфейса, @Binds всегда более эффективен, так как избегает накладных расходов на вызов метода.

Пример совместного использования и преимущества @Binds

// Конкретная реализация с @Inject конструктором
class UserRepositoryImpl @Inject constructor(
    private val apiService: ApiService
) : UserRepository { ... }

// Интерфейс
interface UserRepository { ... }

// Модуль, использующий @Binds для связи
@Module
abstract class RepositoryModule {
    // Эффективно связывает реализацию с интерфейсом
    @Binds
    abstract fun bindUserRepository(impl: UserRepositoryImpl): UserRepository
}

В этом примере Dagger самостоятельно создает UserRepositoryImpl через его @Inject конструктор. Метод @Binds лишь указывает, что этот экземпляр следует использовать для удовлетворения запросов к типу UserRepository. Это делает граф более эффективным и декларативным.

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