의존관계 주입 방법
의존관계 주입 방법은 크게 네가지가 있다.
참고로 의존관계 자동 주입은 스프링 컨테이너과 관리하는 스프링 빈이어야 동작한다.
1. 생성자 주입
@Component
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
}
특정 클래스가 @ComponentScan에 의해 빈으로 등록되고,
그 때 생성자를 호출할 때 @Autowired가 있으면 스프링 컨테이너에서 스프링 빈을 꺼내 객체를 생성자로 주입해준다.
- 호출 시점에 딱 1번 호출되는 것이 보장 ⇒ 불변, 필수 의존관계에 사용
생성자가 딱 1개 있으면 @Autowired 생략 가능
→ 자동으로 주입
💡 생성자 주입을 선택하라
1. 불변
대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경하면 안된다.
수정자 주입을 사용하면 set 메서드를 public으로 변경 가능하게 열어 두어야 한다.
변경하면 안되는 메서드를 열어두는 건 좋은 설계 방법이 아니다.
생성자 주입은 객체 생성시 딱 1번만 호출되므로 불변하게 설계할 수 있다.
2. 누락
생성자 주입을 사용하면 주입 데이터를 누락했을 때 컴파일 오류가 발생한다.
수정자 의존관계일 경우 의존관계 주입이 누락된다면, 프레임워크 없이 순수한 자바 코드로 단위 테스트를 할 때 실행은 되지만 실행 결과는 NPE이 발생한다.
3.final 키워드
생성자 주입만 필드에 final 키워드를 사용 할 수 있다.
필수 필드인 final이 붙인 필드에 값이 설정되지 않으면 컴파일 오류가 발생한다.
수정자 주입을 포함한 나머지 주입 방식 모두 생성자 이후에 호출(객체가 생성된 다음에 호출) 되므로 필드에 final 키워드 사용할 수 없다.
2. setter 주입
@Component
public class OrderServiceImpl implements OrderService {
private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;
@Autowired
public void setMemberRepository(MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
@Autowired
public void setDiscountPolicy(DiscountPolicy discountPolicy) {
this.discountPolicy = discountPolicy;
}
}
필드의 값을 변경하는 수정자 메서드(setter)를 통해 의존관계 주입
처음으로는 생성자로 주입이 일어나고, setter주입은 두번째로 일어남
- 선택, 변경 가능성이 있는 의존관계에 사용
3. 필드 주입
@Component
public class OrderServiceImpl implements OrderService {
@Autowired
private MemberRepository memberRepository;
@Autowired
private DiscountPolicy discountPolicy;
}
필드에 바로 주입
외부에서 변경 불가능해 테스트(순수한 java 테스트 코드로)하기 힘들다는 단점이 있다.
권장 x
4. 일반 메서드 주입
@Component
public class OrderServiceImpl implements OrderService {
private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;
@Autowired
public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
}
일반 메서드에 @Autowired를 사용해 주입
- 한번에 여러 필드 주입 가능
- 잘 사용 x
옵션 처리
@Autowired의 기본값은 required = true로, 자동 주입할 대상이 없으면 오류가 발생한다.
자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다.
//자동 주입할 대상이 없으면 수정자 메서드 자체가 호출이 안됨
@Autowired(required = false)
public void setNoBean1(Member member) { // Member는 스프링 빈이 아닌 객체이므로 오류 발생
System.out.println("setNoBean1 = " + member);
}
//자동 주입할 대상이 없으면 null 입력
@Autowired
public void setNoBean2(@Nullable Member member) {
System.out.println("setNoBean2 = " + member);
}
//자동 주입할 대상이 없으면 Optional.empty 입력
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
System.out.println("setNoBean3 = " + member);
}
@RequiredArgsConstructor
이전
@Component
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
// 생성자 1개 있으면 @Autowired 생략 가능
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
}
@RequiredArgsConstructor 사용 이후
@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;
}
롬복 라이브러리가 제공하는 @RequiredArgsConstructor 를 사용하면
final이 붙은 필드를 모아 생성자를 자동으로 만들어준다.
최근에는 생성자를 딱 1개 두고, @Autowired를 생략하는 방법을 주로 사용한다.
여기에 @RequiredArgsConstructor를 함께 사용한다.
조회 빈이 2개 이상일 때
@Autowired 는 타입으로 조회한다.
@Autowired
private DiscountPolicy discountPolicy // = ac.getBean(DiscountPolicy.class)
타입으로 조회할 때 해당 타입의 빈이 2개 이상이면 오류(NoUniqueBeanDefinitionException)가 발생한다.
이 때 하위 타입으로 지정할 수도 있지만, DIP를 위배하고 유연성이 떨어진다.
그리고 이름만 다르고 완전히 똑같은 타입일 경우 해결이 안된다.
해결 방법
1. @Autowired 필드명 매칭
필드명을 빈 이름으로 변경
@Autowired
private DiscountPolicy discountPolicy -> private DiscountPolicy rateDiscountPolicy
@Autowired는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.
2. @Qualifier
추가 구분자를 붙여주는 방법이다.
빈 등록시 @Qualifer를 붙여준다.
@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}
주입 시 등록한 이름을 적어줌
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
@Qualifier("mainDiscountPolicy") DiscountPolicy
discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
1. @Qualifier 끼리 매칭한다.
2. 못찾을 시 Qualifier에 명시한 이름과 같은 빈 이름을 찾는다.
3. 그래도 못찾을 시 NoSuchBeanDefinitionException가 발생한다.
3.@Primary
우선 순위를 정하는 방법이다.
@Autowired 시에 여러 빈이 매칭되면 @Primary를 가진 빈이 우선권을 가진다.
@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}
@Primary는 기본값 처럼 동작, @Qualifier는 매우 상세하게 동작한다. 우선권은 후자가 높다.
조회한 빈이 모두 필요할 때 - List, Map
해당 타입의 빈이 모두 다 필요한 경우에 사용
public class AllBeanTest {
@Test
void findAllBean(){
ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
// 스프링 컨테이너는 생성자에 클래스 정보를 받는다.
// 여기에 클래스 정보 넘기면 해당 클래스가 스프링 빈으로 자동 등록된다.
// new 로 스프링 컨테이너를 생성 -> 클래스 정보 파라미터로 해당 클래스를 스프링 빈으로 등록
// == 스프링 컨테이너를 생성하면서, 동시에 AutoAppConfig, DiscountService를 스프링 빈으로 자동 등록한다.
DiscountService discountService = ac.getBean(DiscountService.class);
Member member = new Member(1L, "userA", Grade.VIP);
int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
assertThat(discountService).isInstanceOf(DiscountService.class);
assertThat(discountPrice).isEqualTo(1000);
int rateDiscountPrice = discountService.discount(member, 20000, "fixDiscountPolicy");
assertThat(discountPrice).isEqualTo(2000);
}
static class DiscountService{
private final Map<String, DiscountPolicy> policyMap;
private final List<DiscountPolicy> policies;
public DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> policies) {
this.policyMap = policyMap; // Map으로 모든 DiscountPolicy를 주입받음
this.policies = policies; // DiscountPolicy 타입으로 조회한 모든 빈을 담음
System.out.println("policyMap = " + policyMap);
System.out.println("policies = " + policies);
}
public int discount(Member member, int price, String discountCode) {
DiscountPolicy discountPolicy = policyMap.get(discountCode); // discountCode로 map에서 스프링 빈을 찾아서 실행한다.
return discountPolicy.discount(member, price);
}
}
}
자동, 수동의 올바른 실무 운영 기준
-컴포넌트 스캔과 자동 주입과 같은 편리한 자동 기능을 기본으로 사용하자.
-직접 등록하는 기술 지원 객체(기술적인 문제, AOP..)는 수동으로 등록하자.
-다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자.
참고) 스프링 핵심 원리 기본편
'BACK > SPRING' 카테고리의 다른 글
| [Spring] 스프링 핵심 원리 - 빈 스코프 (0) | 2024.03.04 |
|---|---|
| [Spring] 스프링 핵심 원리 - 빈 생명주기 콜백 (0) | 2024.03.04 |
| [Spring] 스프링 핵심 원리 - 컴포넌트 스캔 (0) | 2024.01.31 |
| [Spring] 스프링 핵심 원리 - 싱글톤 컨테이너 (1) | 2024.01.30 |
| [Spring] 스프링 핵심 원리 - 스프링 컨테이너와 스프링 빈 (0) | 2024.01.30 |