@Provides 와 @Binds

요즘 Hilt를 사용 중인데, 자꾸 무의식적으로 `@Provides`, `@Binds`를 붙이는 것 같아 이번에 좀 자세히 정리하고 넘어가겠다.

 

Hilt에 대한 포스팅을 이전에 세 개정도 했는데, 그거랑은 별개로 올린다. Hilt는 컴파일 타임에 Hilt 의존성 그래프를 만든다. 그래서 어노테이션 컴파일러를 사용하고 어노테이션을 붙여서 컴파일러한테 알린다. 이때 의존성 제공 방식으로 @Provides와 @Binds가 있다. 이외의 것도 있지만 이번에는 이 두개만 보겠다.

# `@Provides`

얘는 메서드 본문에서 객체 생성, 반환이 가능하다. 객체 생성 방법을 정의할 수 있는 곳에 붙이고, 그래서 abstract로 정의한 모듈에는 못붙인다... 초기화로직이 직접적으로 필요할 경우에 @Provides로 지정해서 사용한다.

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {
    @Provides
    @Singleton
    fun provideRetrofit(): Retrofit {
        return Retrofit.Builder()
            .baseUrl(BuildConfig.MOCK_URL)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

object로 선언된 모듈안에 존재하며 객체를 직접 생성해서 반환한다.

복잡한 초기화로직에도 사용된다. 예를 들면 로컬 DB인 Room DB에 접근해야된다면 Room Builder를 통해 AppDatabase 객체를 주입받아야되는데, 이때가 알맞은 @Provides 사용처라고 할 수 있다.

@Provides
@Singleton
fun provideDatabase(@ApplicationContext context: Context): AppDatabase {
    return Room.databaseBuilder(context, AppDatabase::class.java, "test_db")
        .addCallback(object : RoomDatabase.Callback() {
            override fun onCreate(db: SupportSQLiteDatabase) {
                Executors.newSingleThreadExecutor().execute {
                    val database = provideDatabase(context)
                    val initialData = listOf(/* 초기 데이터를 넣어준다 */)
                    database.dataDao().insertAll(initialData)
                }
            }
        })
        .build()
}

@Provides가 붙은 모듈을 빼먹다 보면 볼 수 있는 클래스 중 Factory가 붙은 걸 본적이 있을 것이다. @Provides어노테이션이 붙어있으면 Hilt가 컴파일타임에 해당 메서드를 분석해서 팩토리 클래스를 생성한다. 런타임 때 객체 생성할 준비를 하는 것이다.

# `@Binds`

abstract 클래스나 인터페이스의 구현체를 바인딩할 때 사용한다. 추상화 되어있는 곳에 사용하기 때문에 메서드에 본문이 없고 파라미터로 구현체 클래스를 받게된다. 단순 인터페이스 - 구현체를 연결하는 형태다.

interface TestRepository
class TestRepositoryImpl @Inject constructor() : TestRepository
// 인터페이스랑 구현체가 이미 있다고 가정하겠다. 이거까지하면 너무 길어진다.

@Module
@InstallIn(SingletonComponent::class)
abstract class RepositoryModule {
    @Binds
    abstract fun bindTestRepository(testRepositoryImpl: TestRepositoryImpl): TestRepository
}

추상클래스로 선언된 모듈이다. 

한 인터페이스에 대한 여러개의 구현체가 존재할 수도 있다. 이럴 때는 @Binds와 Qualifier를 같이 써주면된다. @Named를 사용해도 된다. Qualifier는 물론 꼭 Binds가 아니라도 아래처럼 @Provides에서 사용할 수도 있다.

@Singleton
@Provides
fun provideNotificationApi(
    @NormalRetrofit
    retrofit: Retrofit
): NotificationApi = retrofit.create()

@Singleton
@Provides
fun provideTmapApi(
    @TmapRetrofit
    retrofit: Retrofit
): TmapRouteApi = retrofit.create()

 

차이점을 정리해보면 Provides는 객체 생성, 외부 라이브러리 주입과 같은 구체적인 객체가 필요할 때 사용하고, Binds는 인터페이스와 구현체와의 바인딩에서 사용된다. 객체 지향적, 의존성 역전 개념에서 보면 Binds가 더 클린한 형태다. 컴파일 타임에 그려진 Hilt 의존성 그래프에 드러나기 때문이다. 컴파일타임에 바인딩 정보를 미리 알 수 있다는 건 그만큼 런타임 때 성능이 좋다는 말과 같다. Provides는 런타임 때 객체를 생성하긴 해도 객체 생성과정을 제어할 수 있어서 좀 더 자유롭다.

 

런타임 때 정확히 어떤일이 일어나는지에 대해서는 아래와 같이 정리할 수 있겠다.

• `@Provides`는 Hilt가 생성해준 팩토리의 get()으로 호출되어 실제 객체 인스턴스를 생성한다. 객체 생성과정에서 @Provides 달아둔 메서드가 실행되는 것이다.
• `@Binds`는 이미 컴파일 타임에 Hilt 의존성 그래프에 바인딩 정보가 다 올라가 있는 상태다. 따라서 그냥 로직 실행 없이 바로 구현체 인스턴스를 꽂아준다.

얼마전에 Paging3를 아키텍쳐에 맞게 가공했어야했는데 Paging이 Repository와 같은 수준임을 알기 전에 DataSource인줄 알고 별 이상한 짓을 하다가 PagingSource를 생성해주는 Factory를 만들어서 @Binds해준적이있다. 나중에 그게 잘못된 패턴임을 알고 신속하게 고쳤다.

 

 

도움이 됐다면 댓글이나 공감 버튼 한 번씩 누르고 가주세요!