ViewModel이 Repository 인터페이스를 주입받는 이유

Question

이 부분의 궁금증이 해결되지 않아 여쭤봅니다! ViewModel에서 Repository를 생성자로 받을 때 그냥 @Inject 키워드를 써서 클라스를 주입받지 않고 인터페이스를 굳이 만들어 @Module 로 바인딩을 하고 주입받는지 이유가 궁금합니다. 즉 왜 Reposiory와 RepositoryImpl을 나누는 걸까요?

jminie · Answer

파라미터는 하나만을 사용할 수 있으며 이 때 파라미터의 타입은 반환타입이 될 수 있는것만 사용할 수 있다 -> 여기서 파라미터가 RepositoryImpl이고 이 Impl은 Repositroy를 상속받고 있으므로 반환타입이 될 수 있는 것만 사용할 수 있다라는 조건에 부합하는건가요???? (반환타입이 Repository 인터페이스이므로 파라미터인 RepositoryImpl은 다형성으로 인해 Repository 반환타입으로 볼 수 있다.)   제가 이해한게 맞을까요? 추가로 Impl을 주입할 경우 (인터페이스가 없고 구현클래스만 있다는 가정) 외부 라이브러리나 빌더 패턴으로 만든 클래스가 아니므로 @Provides를 이용하지 않고 그냥 @Injcet를 통해서 주입해도 되지 않나요? (물론 객체지향의 추상화나 DIP에는 맞지 않게지만요!)

냉동코더 · Answer

질문하신것처럼 Impl을 provides로 주입할 수도 있지만 여기서는 binds를 사용했습니다. 결과가 동일해 보이는 작업이고 provides로 주입하는게 더 간단해 보이는데 굳이 binds를 사용한 가장 큰 이유는 provides와 binds의 사용법을 둘 다 보여주기 위한 것입니다... 만 기술적으로 차이도 있습니다. @Binds 는 abstract 메소드에만 붙일 수 있고 파라미터는 하나만을 사용할 수 있으며 이 때 파라미터의 타입은 반환타입이 될 수 있는것만 사용할 수 있다는 제한사항 이 있습니다. @Binds 는 그래서 사실상 제한된 조건하에서만 사용가능한 @Provides 와 같은데요, hilt가 신경써야 할 부분이 적어지기 때문에 내부적으로 자동생성하는 코드 양이 감소한다는 특징 이 있습니다. 그래서 인터페이스의 구현체를 의존객체로 제공할 경우 @Provides 대신 @Binds 를 사용하면 오버헤드를 줄일 수 있습니다. 또한 뷰모델에 인터페이스가 주입되도록 코드를 작성할 수 있으므로, 필요할 경우 주입하는 구현체 종류를 뷰모델 코드를 건드리지 않고 외부에서 변경할 수 있다는 장점도 있습니다.