-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
@configuration과 싱글톤
@Configuration
public class AppConfig {
// 리팩토링 : 역할 = 메서드 명, 구현 = new로 생성한 객체
@Bean
public MemberService memberService(){
return new MemberServiceImpl(memberRepository()); // 생성자 주입 -> MemberServiceImpl 클래스가 더이상 MemberRepository의 구현체에 의존하지 않음
}
@Bean
public MemberRepository memberRepository() {
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService(){
return new OrderServiceImpl(memberRepository(), discountPolicy());
}@bean memberService → new MemoryMemberRepository()
@bean orderService → new MemoryMemberRepository()
Q. 이렇게 되면 MemoryMemberRepository 구현체가 각각 2개가 생성되어서 싱글톤이 깨지는 것 아닌가요!?
A. Test로 검증해본 결과 모두 같은 MemberRepository 인스턴스이다.
@Configuration
public class AppConfig {
// 리팩토링 : 역할 = 메서드 명, 구현 = new로 생성한 객체
@Bean
public MemberService memberService(){
System.out.println("call AppConfig.memberService");
return new MemberServiceImpl(memberRepository()); // 생성자 주입 -> MemberServiceImpl 클래스가 더이상 MemberRepository의 구현체에 의존하지 않음
}
@Bean
public MemberRepository memberRepository() {
System.out.println("call AppConfig.memberRepository");
return new MemoryMemberRepository();
}
@Bean
public OrderService orderService(){
System.out.println("call AppConfig.orderService");
return new OrderServiceImpl(memberRepository(), discountPolicy());
}- 예측 : 총 5회의 call
memberService → memberRepository
orderService → memberRepository
memberRepository
- 결과 : 총 3회의 call
memberService
memberRepository → 3번이 아닌, 1번만 호출됨 → 스프링이 싱글톤 보장을 해주는구나!! 근데 어떻게!? → 다음시간 설명
orderService
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels