Чем Binds лучше чем Provides?

Разбор @Binds vs @Provides в Dagger

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

Ключевые преимущества @Binds перед @Provides

1. Производительность и эффективность компиляции

@Binds — это абстрактный метод, который не содержит исполняемого кода. Dagger использует его только для указания связи между типом и его реализацией. Это означает:

• Меньше сгенерированного кода: Dagger не создаёт отдельный метод-провайдер в сгенерированном классе модуля.
• Быстрее компиляция: Упрощается процесс кодогенерации.
• Оптимизация времени выполнения: Нет дополнительных вызовов методов в графе зависимостей.

2. Лаконичность и читаемость кода

С @Binds код становится чище, особенно при простых привязках.

Пример с @Provides:

@Module
class NetworkModule {
    @Provides
    fun provideApiService(retrofit: Retrofit): ApiService {
        return retrofit.create(ApiService::class.java)
    }
}

Пример с @Binds:

@Module
abstract class NetworkModule {
    @Binds
    abstract fun bindApiService(apiServiceImpl: ApiServiceImpl): ApiService
}

Обратите внимание: с @Binds мы сразу связываем интерфейс ApiService с его конкретной реализацией ApiServiceImpl, не написав ни строчки реализации. Однако для этого нужен abstract класс и метод.

3. Предотвращение дублирования логики

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

Проблема с @Provides:

@Provides
fun provideRepository(api: ApiService, db: Database): Repository {
    return RepositoryImpl(api, db) // Создаём новый объект
}

Решение с @Binds:

@Binds
abstract fun bindRepository(repoImpl: RepositoryImpl): Repository

Здесь RepositoryImpl уже должен быть предоставлен где-то ещё в графе. @Binds просто указывает, что когда запрашивают Repository, нужно использовать существующий экземпляр RepositoryImpl.

Когда использовать @Provides, несмотря на всё вышесказанное

@Binds не всегда может заменить @Provides. Есть ситуации, где @Provides незаменим:

1. Когда требуется сложная логика создания объекта: Если нужно выполнить вычисления, конфигурацию или условную логику.

   @Provides
   fun provideOkHttpClient(cache: Cache): OkHttpClient {
       return OkHttpClient.Builder()
           .cache(cache)
           .addInterceptor(LoggingInterceptor())
           .connectTimeout(30, TimeUnit.SECONDS)
           .build()
   }
   

2. Когда объект не является реализацией интерфейса: Например, при связывании примитивов (String, Int) или классов без общего интерфейса.

   @Provides
   fun provideBaseUrl(): String = "https://api.example.com"
   

3. Когда требуется аннотация @Singleton или другой скоуп на методе: В abstract методах с @Binds нельзя использовать аннотации скоупов (хотя их можно ставить на саму реализацию класса).

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

• Используйте @Binds когда нужно просто связать интерфейс с его реализацией, и эта реализация уже предоставлена в графе зависимостей.
• Используйте @Provides когда:
  • Требуется сложная инициализация
  • Вы работаете с примитивами или классами без интерфейсов
  • Нужно создать объект "с нуля" с дополнительной конфигурацией
• Комбинируйте подходы: Часто в одном модуле используются оба метода для разных целей.

Итог

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