Hilt(2) - 바인딩과 의존성 주입

# Binding?

flowchart LR
    Android -->|Compile, Request| Hilt
    Hilt -->|Runtime, Inject| Android
    AppModule ---> Hilt
    NetworkModule ---> Hilt

의존성을 추가하는 행위나 개별적인 인스턴스 dependency(Inject로 되어있는) 모두 바인딩이라고 한다. 그냥 의존성을 바로 꽂을 수도 있고, 의존성을 관리할 모듈을 둬서 모듈을 HiltComponent에 꽂아 사용하기도 한다.

# Dependency Injection - 생성자 주입, 필드 주입, 메서드 주입

// 생성자 주입
class Test @Inject constructor(foo: Foo){ // foo 주입과 동시에 Test 바인딩
 
}
// 필드 주입
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {

    @Inject // 얘는 요청해서 주입 받는 것
    lateinit var test: Test
    ...
}
// 메서드 주입
@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    
    @Inject
    fun foo(bar: Bar){
	...
}

생성자 주입과 필드주입은 이전 게시글에서 확인했다. 메서드 주입만 보면 되는데, foo 메서드는 bar라는 파라미터의 의존성을 주입받게 된다.

 

생성자 주입은 따로 스코프 없이 Inject해버리는데 이 경우 Test 클래스 자체도 컴파일 타임에 Hilt 컴포넌트에 바인딩된다는 특이점이 있다.  메서드 주입은 Inject가 `super.onCreate` 이후에 작동하기 때문에 이 메서드에서 lateinit var를 초기화할 수 도 있다.

lateinit var fooFun: Foo

@Inject // method 주입
fun provideFoo(foo: Foo){ // super.onCreate 이후에 Inject되어 fooFun은 초기화 된 상태로 접근가능하다.
    fooFun = foo
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    assert(this::fooFun.isInitialized) // true이기 때문에 crash 발생하지 않음
	...
}

근데 모듈을 사용하기 때문에 메서드 주입은 아무래도 사용하는 빈도가 적을 것 같다.

# `@Qualifier` , `@Named("식별명")`

Hilt는 타입을 기준으로 의존성을 구분하는데 그래서 중복 바인딩이 발생하면 오류가 발생한다. 동일한 타입의 두 의존성을 구분하지 못하기 때문이다. -> `Dagger/DuplicateBindings` 로 에러가 나온다. 근데 타입은 동일하지만 역할이 다른 경우 두 가지 모두 살려야할 때가 있다. 예를 들면 Access Token으로 접근해야 되는 의존성과 그게 없어도 접근 가능한 의존성 이렇게 두개로 나눌 때가 그 예시다.  이 경우 Qualifier로 구분할 수 있다.

 

사용 방법은 은근히 간단하다.

@Qualifier
annotation class TestQualifier

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

    @Provides
    fun provideTest(): Test {
        return Test(id = "Test")
    }

    @TestQualifier
    @Provides
    fun provideTest2(): Test {
        return Test(id = "TestQualifier")
    }
}

Qualifer 어노테이션을 달고있는 커스텀 Qualifier annotation을 만들고, 그걸 중복바인딩이 필요한 곳에 달아주면 된다.

@Inject
lateinit var test1: Test

@TestQualifier
@Inject
lateinit var test2: Test

// 메서드 주입의 경우
@Inject
fun injectTest(@TestQualifier test: Test){
    testQualifier = test
}

물론 주입받을 곳에도 달아줘야된다.

껍데기만 만들어두고 사용할 수도 있지만 속성을 정의하는 방식으로 사용하는 것도 가능하다.

@Qualifier
annotation class TestQualifier(val id: String)

이렇게 정의하면 Inject나 바인딩 할 때 속성값인 key를 명시해줘야한다.

이런 식별과정을 좀 더 쉽게하는 방법이 `@Named`인데 식별명 문자열을 id로 갖는 Qualifier라고 보면 될 것 같다.

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

//    @TestQualifier
    @Named("Test")
    @Provides
    fun provideTest2(): Test {
        return Test(id = "TestQualifier")
    }
}

한 데 모아 관리하길 좋아하는 사람들은 아마 Named 보다 Qualifier를 선호하지 않을까 생각한다.

# Lazy와 Provider

Hilt의 Lazy 주입은 by lazy과 특정시점에 인스턴스를 생성한다는 점에서 약간 비슷하다. 인스턴스 생성시점을 조절한다는 의미는 생성비용이 커서 이걸 조절하겠다는 의미도 될 수 있다.

@Inject
lateinit var foo: Lazy<Foo> // Lazy

...
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    assert(foo.get().bar != null)

get으로 Lazy 주입을 받아올 수 있는데, 주의할 점은 Lazy가 dagger 라이브러리의 타입이라는 것이다. 코틀린도 Lazy를 갖고있기 때문에 import를 잘못하면 get으로 못가져온다.

Lazy로 선언한 인스턴스는 한번 주입되면 같은 인스턴스를 반환한다.

@Inject
lateinit var fooProvider: Provider<Foo>

Provider도 비슷하다. get으로 가져오고, 호출할 때 인스턴스를 생성한다. Lazy와 다른 점은 Lazy는 한번 생성되면 그걸 가져오는 거고, Provider는 매 호출마다 새 인스턴스를 가져온다. 그래서 각 호출에 대해 동일한 인스턴스를 반환하고 싶다면 Scope를 지정해서(`@Singleton`을 붙인다던가) 사용하는 방법을 선택해야된다.

# 바인딩 기법 - `@Binds`

바인딩은 DI 그 자체(컴포넌트에 의존성을 추가하는 행위) 또는 그 의존성 자체를 의미한다.

모듈 안에서 컴포넌트에 달아놓는 `@Provides`는 이제 익숙해졌다. 기존에 Provide 된 바인딩이 있으면 `@Binds`로 효율적으로 달아 둘 수 있게 된다. Binds가 중요한 이유는 언어 특성상 인터페이스 타입으로 선언된 변수에 하위 타입으로 바인딩을 걸 수 있기 때문이다.

 

즉 `@Binds`는 이미 바인딩 된 의존성을 확장관계에 있는 새 타입으로 감싸서(선택적으로 모듈 설치가 가능하다) 바인딩 시킬 때 효율적으로 동작한다. 따라서 제약 조건이 존재하는데,

1. `@Binds`는 모듈 내 abstract 메서드에 추가돼야한다.
2. 파라미터를 한 개만 가질 수 있다.
3. 파라미터 타입이 반환 타입의 서브타입이어야 한다.
4. `@Scope` 및 `@Qualifier` 랑 같이 쓸 수 있다. 

1, 2, 3 모두 확장이 용이한 언어특성을 그대로 반영한 조건들임을 알 수 있다.

abstract 메서드는 구현체가 필요한 경우라 이것만으로는 인스턴스를 생성할 수 없는데, provides는 그게 아니기 때문에 주의해야된다.(파일 자체를 분리 시켜버리는 게 좋다.) 네이밍규칙은 `bind서브타입`으로 시작한다.

@Module
@InstallIn(SingletonComponent::class)
// Binds를 위한 추상 모듈을 만들어 준다
abstract class EngineModule {
    @Binds
    abstract fun bindGasolineEngine(engine: GasolineEngine): Engine

    @Binds
    abstract fun bindDieselEngine(engine: DieselEngine): Engine
}

Engine은 인터페이스고, GasolineEngine, DieselEngine은 생성자 바인딩으로 컴포넌트에 달려있는 상태다. 이대로만 놔두면 Engine을 반환하는 게 중복돼서 중복바인딩을 허용하지않는 Hilt 특성상 에러가 발생한다. Named나 Qualifier로 해결하면 되는 부분이기 때문에 이건 필요에 따라 다르게 사용하면 될 것 같다.

 

# 옵셔널 바인딩  `@BindsOptionalOf`

바인딩 되어 있을 수도 있는 의존성을 요청하는 어노테이션이다. 옵셔널이기 때문에 바인딩 되지않아도 일단 컴파일 에러는 발생하지 않는다. 바인딩이 안된 경우도 있을 수 있기 때문에 기본적으로 파라미터를 가지면 안된다. 또 받아올 의존성도 Optional해야되기 때문에 생성자 바인딩 된 의존성들은 이때 사용할 수 없다.

@Provides
fun provideFoo(): Foo{
    return Foo()
}

그래서 BindsOptionalOf는 따로 provide된 의존성을 달아줘야된다.

@BindsOptionalOf
abstract fun bindDieselEngine(): Engine

이렇게 하는 방법 말고 의존성 그래프 상의 관계에서 모두 `Optional<T>`로 선언해주는 방법도 있다.

@Inject
lateinit var foo: Optional<Foo>

BindsOptionalOf로 바인딩 된 의존성을 요청할 때는 Optional로 감싸서 해주고,  get()으로 가져온다.

바인딩 되지않았다면 예외가 발생하기 때문에 isPresent로 체크해줘야된다. 

`@BindsInstance`는 컴포넌트 생성과 동시에 바인딩 되는 걸 말한다. 근데 이건 따로 외부 컴포넌트를 만들어서 사용할 때 주로 사용한다...

 

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