Приведи пример когда можно Provides поменять на Binds

@Provides и @Binds в Dagger: когда и зачем менять

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

Ключевое отличие

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

Пример замены @Provides на @Binds

Рассмотрим классический случай: у нас есть интерфейс AnalyticsTracker и его конкретная реализация FirebaseAnalyticsTracker.

Исходный вариант с @Provides:

// Интерфейс
interface AnalyticsTracker {
    fun trackEvent(eventName: String)
}

// Конкретная реализация
class FirebaseAnalyticsTracker @Inject constructor() : AnalyticsTracker {
    override fun trackEvent(eventName: String) {
        // Реальная логика отправки в Firebase
        println("Firebase tracking: $eventName")
    }
}

// Модуль Dagger
@Module
class AnalyticsModule {

    @Provides
    fun provideAnalyticsTracker(firebaseTracker: FirebaseAnalyticsTracker): AnalyticsTracker {
        // Метод создает и возвращает объект.
        // В данном простом случае он просто возвращает готовый инстанс.
        return firebaseTracker
    }
}

В этом модуле метод provideAnalyticsTracker лишь возвращает параметр. Dagger сначала должен предоставить FirebaseAnalyticsTracker (через его конструктор с @Inject), а затем вызвать этот метод. Это создает небольшие издержки во время компиляции и выполнения.

Улучшенный вариант с @Binds:

@Module
abstract class AnalyticsModule { // Модуль становится abstract!

    @Binds
    abstract fun bindAnalyticsTracker(firebaseTracker: FirebaseAnalyticsTracker): AnalyticsTracker
    // Абстрактный метод. Никакого тела, только сигнатура.
    // Он говорит Dagger: "Везде, где требуется AnalyticsTracker, используй FirebaseAnalyticsTracker".
}

Почему эта замена корректна и предпочтительна?

1. Производительность. Метод @Binds — абстрактный. Dagger не генерирует код для его вызова в runtime. Он использует эту информацию на этапе компиляции для построения графа зависимостей. Это делает код более эффективным.
2. Лаконичность. Убирается шаблонный код, который лишь возвращает один параметр.
3. Читаемость. Намерение становится предельно ясным: "связать абстракцию с конкретной реализацией".

Когда замена НЕВОЗМОЖНА?

Использовать @Binds можно только в абстрактном модуле (abstract class). Его нельзя применить, если в методе необходима какая-либо логика помимо возврата инстанса. Вот случаи, где обязательно нужен @Provides:

• Создание объекта с нетривиальной логикой:

  @Provides
  fun provideOkHttpClient(cache: Cache): OkHttpClient {
      return OkHttpClient.Builder()
          .cache(cache)
          .addInterceptor(LoggingInterceptor()) // Конфигурация
          .connectTimeout(30, TimeUnit.SECONDS) // Установка параметров
          .build()
  }
  

• Предоставление экземпляра, который не принадлежит вам (например, из сторонней библиотеки):

  @Provides
  fun provideGson(): Gson {
      return GsonBuilder().setDateFormat("yyyy-MM-dd").create() // Кастомная настройка
  }
  

• Предоставление String, Int или других примитивов, которые требуют квалификаторов (например, @ApplicationContext):

  @Provides
  @Named("ApiUrl")
  fun provideApiUrl(): String {
      return BuildConfig.API_BASE_URL
  }
  

Итог

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