@ComponentScan 개념 이해하기

 

 

@Component는 구현체에 달아 놓는 것이다. 인터페이스(추상체)에 달아 놓는 것이 아니다.)

이말은 즉, 스프링 컨테이너에는 추상체가 등록되는 것이 아니라 구현체가 등록되는 것.

---

 

해당 예시 코드에서 구현체가 아닌 추상체를 Dependency Injection 하는 모습인데, 우측 스프링 컨테이너를 보면 추상체가 아니라 구현체가 해당 추상체를 가르키는 것으로 보인다. 

무슨 의미일까?

 

DIP(Dependency Injection Principal)을 위해 코드 상에는 추상체에 의존하게 설계해야한다.

하지만 AppConfig, AutoAppConfig 등의 파일을 따로 관리하지 않는 @ComponentScan 방식을 따를 경우 

DIP를 위반하고 코드 상에서 구현체를 의존하게 하는 방법밖에 떠오를 수가 없을 것이다.

 

하지만 해결 방법은 존재한다.

 

바로 스프링 컨테이너에 등록된 빈들이 "value"라면

인터페이스 클래스는 그 빈들을 꺼낼 수 있는 "key"로써 사용된다.

 

즉, 인터페이스 클래스(MemberRepository)는 스프링 컨테이너에 저장되어 있는 memoryMemberRepository를 꺼낼 수 있는 열쇠라는 의미.

 

근데 여기서 반문.

---

그럼 스프링 빈에 2가지 이상의 구현체가 등록(1가지 추상체를 기반)된 경우는 어떡하나?

 

이에 대한 해답은 @Qualifier, @Primary 등을 사용하면 해결이 된다.