∨ 부모타입으로 조회 => 자식빈들이 다 끌려나옴
cf. Object타입으로 조회하면 다 조회된다.
.
.
부모타입으로 조회하는 경우 발생할 수 있는 여러 케이스들을 만나보자.
각 케이스에 대한 테스트코드를 작성해보며 진행하자.
※ 참고 : test코드에서 print문 찍어서 눈으로 확인하는 건 실제로 별로 의미 없고 할 일도 없다.
지금은 그냥 학습용도로 찍어보는 것이다.
실무에서는 테스트 통과&실패 사실만 의미있음!
.
.
∨ TestConfig :
@Configuration
static class TestConfig {
@Bean
public DiscountPolicy reteDiscountPolicy() {
return new RateDiscountPolicy();
}
@Bean
public DiscountPolicy fixDiscountPolicy() {
return new FixDiscountPolicy();
}
}
● 같은 부모타입 자식이 둘 이상 있으면 => 중복오류 발생
∨ Test :
@DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면 => 중복오류 발생")
void findBeanByParentTypeDuplicate() {
DiscountPolicy bean = ac.getBean(DiscountPolicy.class);
}
=> NoUniqueBeanDefinitionException 발생 => assertThrows 사용하게끔 Test 수정
@Test
@DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면 => 중복오류 발생")
void findBeanByParentTypeDuplicate() {
assertThrows(NoUniqueBeanDefinitionException.class,
() -> ac.getBean(DiscountPolicy.class));
}
부모타입으로 getBean할 때 이런 중복오류를 피하려면,
getBean에 찾으려는 자식빈 이름을 명시해주면 된다 (당연스레!!) ↓
● 부모타입으로 조회 & 자식이름 지정하여 getBean
부모타입으로 조회하고 싶은데 자식빈이 여러개면..
당연히 자식이름 지정해서 getBean하면 되겠쥐
∨ Test
@Test
@DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면 => 빈이름 지정하면 됨")
void findBeanByParentTypeBeanName() {
DiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy", DiscountPolicy.class);
assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
}
● 특정 하위타입으로 조회 가능
이것도 어쩌면 당연해보인다!
∨ Test
@Test
@DisplayName("특정 하위 타입으로 조회")
void findBeanBySubType(){
RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
}
● 부모 타입으로 모두 조회하기
∨ Test
@Test
@DisplayName("부모 타입으로 모두 조회하기")
void findAllBeanByParentType() {
Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
assertThat(beansOfType.size()).isEqualTo(2);
for (String key : beansOfType.keySet()) {
System.out.println("key = " + key + " value = " + beansOfType.get(key));
}
}
실제로 컨테이너에서 getBean으로 스프링빈 객체 꺼내볼 일은 거의 없다고 한다.
그래도 기본기능이라 학습하는 거라고 하셨음!!
∨ 실제로는 getBean으로 객체를 확인할 일이 별로 없는 이유는 :
@Configuration 클래스에서 애플리케이션의 모든 구성과 의존관계가 스프링빈에 등록이 되고, 컨테이너가 알아서 그 스프링빈들을 관리하기 때문에 다른 클래스에서 의존관계를 신경쓰지 않고 개발할 수 있기 때문이다.
=> 개발할 때, 컨테이너에 등록된 빈을 직접 꺼내 확인할 일이 없다.
=> 서비스 클래스상에서 구현체가아닌 인터페이스에만 의존하는 것과 연관있다 (DIP)
'web +a' 카테고리의 다른 글
컴포넌트 스캔 (0) | 2022.07.08 |
---|---|
싱글톤 컨테이너 (0) | 2022.07.08 |
(컨테이너에 등록된) 스프링 빈 조회해보기 (0) | 2022.07.06 |
스프링 컨테이너 첫 이용 (0) | 2022.07.05 |
IoC/DI컨테이너 (0) | 2022.07.05 |