프로젝트 DI 셋팅을 하기 위해 Module을 만들던 도중, 문득 어노테이션 중 @Binds를 보게 되었다. 주로 이전까지는 아무 생각없이 @Provides를 사용해왔었는데, 반성해야겠다.
@Binds vs @Provides
-
공통점
- @InstallIn로 정의된 모듈 내부에서 종속성 주입을 위해 사용된다.
-
@Binds : 인터페이스와 인터페이스의 구현체를 연결하는데에 사용된다.
- @Binds의 메서드는 추상 메서드여야 한다.고로 abstract 키워드를 요구한다.
- @Binds 메서드는 동일한 인터페이스에 여러개의 인터페이스 구현체를 연결할 수 없다.
- 주입될 타입은 인터페이스이다.
-
@Provides : 종속성 객체를 생성, 제공하는 메서드를 정의할 때 사용된다. (@Binds 외의 경우)
- 종속성을 제공하는데에 의미가 있으므로, 반환값이 존재해야 한다.
- 복잡한 종속성을 제공하거나 외부 라이브러리를 제공하는데에 사용된다.
- 주입될 타입은 인터페이스, 클래스 등 다양하다.
나는 무엇이 문제였고, 어떤 것을 생각하지 않았을까
단순히 생각해보면, 구현할 코드가 한 두줄 줄어든다...뿐이다.
@Module
class MyModule {
@Provides
fun getInjectClass(injectObject: InjectClass): InjectInterface {
return injectObject
}
}
@Module
abstract class MyModule {
@Bindes
abstract fun getInjectClass(injectObject: InjectClass): InjectInterface
}이게 뭐...? 라는 생각이 들 때즈음 포스팅에서 내부적으로 추가 생성하는 코드들에 관한 존재를 알게 됐다.
@Provides는 @Binds가 생성하지 않는 하나의 클래스를 추가로 생성한다.
해당 클래스는 다음과 같다.
이것은 하나의 @Provides가 생성하는 추가 클래스이다. 여러개가 생성하게 된다면, 상당한 코드가 불필요하게 추가되는 것이다.
또한 @Binds vs @Provides는 주입될 객체를 생성하기 위한 로직도 차이가 난다.
그러므로 적절한 사용처에는 @Binds를 사용하는 것이, 미학적으로도 코드적으로도 좋다는 것을 의미한다.
출처 :
안드안드안드