4-2. 빈 조회 ~ 4-5. 상속관계에서 빈 조회
목표 : 모든 빈 조회
( getBeanDefinitionNames : 빈들의 정의의 이름들을 String 배열에 넣는다. )
1. AppConfig.class를 바탕으로 ApplicationContext를 생성하고 빈 이름들 추출해서 배열에 넣는다.
2. 여기서 리스트나 배열같은게 있으면 iter치고 탭 누르면 for문 자동으로 완성. 찾은 빈 이름으로 하나하나 getBean한다.
3. 그 내용출력 ( soutv 는 변수 출력, soutm 은 메서드 출력 )
위에 있는 빈들은 스프링이 내부적으로 쓰는 기반 빈들, 참고로 appConfig도 스프링 빈으로 등록됨.
( 스프링 내부에 있는거 빼고 내가 만든 빈만 출력 하고 싶은데?
만약 ROLE_INFRASTRUCTURE 하면 스프링 기반 빈 들만 출력됨.
---------------------------------------------------------4-3. 스프링 빈 조회 - 기본
- memberService 는 MemberServiceImpl의 instance인가? ( 참 )
- 3번째 메서드만 구현체로 찾았다. ( 구체타입으로 조회하면 변경시 유연성이 떨어진다. )
( getBean(MemberServiceImpl.class)) 이부분.
##############철칙!!!!!!
1. 역할과 구현을 구분해야한다.
2. 역할에 의존해야한다.
이 철칙을 깬 것이므로 좋진않음.
테스트는 실패도 만들어야한다.
없는 이름으로 조회하면 NoSuchBeanDefinitionException 이 터져야한다. -> 예외가 터져야 테스트 성공
assertThrows(터질 예외, 이걸 했을 때)
---------------------------------------------------------4-4. 스프링 빈 조회 - 동일한 타입이 둘 이상
신기한점 : 클래스 안에서 static 클래스 선언하면 큰 클래스 안에서만 쓰겠다 ㅋㅋ @Configuration 다시 설정( 이번 테스트를 위해서 이 클래스 안에서만)
빈의 타입이 같을 수 있음.
Annotation.... 여기에 SameBeanConfig만 설정해두면 스프링 시작할 때 저것만 뜬채로 스프링컨테이너가 올라감. ( 빈 두개만 등록함)
빈을 (이름, 타입) 으로 찾으면 된다.
찬찬히 읽어봐.
---------------------------------------------------------4-5. 스프링 빈 조회 - 상속 관계 ( 매우 중요 )
# 빈 조회의 대원칙
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
- 부모타입으로 조회시 자식빈들도 모두 조회됨.
-> Object 타입으로 조회 = 모든 스프링 빈 조회
테스트 하나하나 씩 곰곰히 생각하면서 읽어라 .
어마어마하게 많은 빈들이 튀어나온다. ( 스프링 내부적으로 쓰는 빈들 )
다 이해됨. 천천히 읽어보기.
- 이 정도 조회 방법만 알아도 충분하다.
- 사실 ApplicationContext에서 Bean을 바로 꺼낼 일은 별로 없다.
### Bean 조회 끝!!!!!!!!!!!!!