1. 다영한 의존관계 주입 방식
-
1) 생성자 주입
- 생성자를 통한 의존 관계 주입 방식
- 생성자 호출 시점에 한 번만 호출 보장
- 생성자 주입은 빈을 등록하면서 의존관계 주입도 동시에 진행
- 2) 수정자 주입(setter 주입)
- setter라는 필드의 값을 변경하는 수정자 메서드를 통한 의존관계 주입 방식
- setXxxx(){}
- 선택적이거나, 변경 가능성이 있는 의존관계에 사용
- 자바빈 프로퍼티 규약의 수정자 메서드 방식 사용
- 규약
class Test {
private int test;
public void setAge(int age){
this.age = age;
}
public int getAge(){
return age;
}
}-
빈 등록 이후 의존관계 주입
-
@Autowired(required = false) 지정 시 주입 대상이 없어도 오류가 나지 않음
-
3) 필드 주입
- 필드 직접 주입
- 외부에서 변경이 불가능 -> 테스트 하기 힘듦(테스트 유연성 부족)
- DI 프레임워크가 없으면 불가능
- 사용 지양
-
4) 일반 메서드 주입
- 한번에 여러 필드를 주입 가능
- 일반적으로 잘 사용 X
2. 옵션처리
AutowiredTest
- Member는 스프링 빈이 아님, @Autowired(required=false) 이므로 호출X (의존관계가 없으면 메서드 호출 X)
3. 생성자 주입을 사용
생성자 주입 권장 이유
- 불변
- 누락 방지
- final 키워드
- 생성자 주입을 사용하면 필드에 final 키워드 사용가능 -> 오류를 컴파일 시점에 확인 가능
✔️ 참고
수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출, 필드에 final 키워드를 사용할 수 없음
생성자 주입 방식만 final 키워드를 사용 가능
✔️ 정리
프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법
기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션 부여, 생성자 주입과 수정자 주입을 동시에 사용 가능
항상 생성자 주입을 선택 -> 그리고 가끔 옵션이 필요하면 수정자 주입을 선택, 필드 주입은 사용X
4. 롬복과 최신 트랜드
- 최근에는 생성자를 딱 1개 두고 , @Autowired를 생략하는 방법을 주로 사용
- Lombok라이브러리의 @RequiredArgsConstructor를 사용한다(final이 붙은 필드를 모아서 생성자를 자동으로 만듦)
5. 같은 타입 조회 빈이 2개 이상 일 때 문제
-
@Autowired는 타입으로 조회하기 때문에 같은 타입의 빈이 2개 이상 일 때 NoUniqueBeanDefinitionException 오류 발생
-
해결방안
6. @Autowired 필드 명, @Qualifier, @Primary
1) @Autowired는 기본적으로 타입 매칭을 시도하고, 여러 개의 빈이 있으면 필드이름, 파라미터 이름으로 매칭을 시도
2) @Qualifier는 추가 구분자를 붙이는 방법 -> 이름을 변경하는 것은 아님
- 빈 등록시 @Qualifier를 붙임
- 주입시 @Qualifier를 붙여주고 등록한 이름을 적음(수정자 주입, 필드 주입도 가능)
참고
- 직접 빈 등록 시에도 @Qualifier를 동일하게 사용가능
@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy(){
return new ...
}
3) @Primary는 우선순위를 정함. @Autowired를 통해 여러번 매칭 시 @Primary 사용하여 우선순위 우위를 부여
7. 애노테이션 생성
- @Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일시 타입 체크X, 런타임시에 확인
- 에 MainDiscountPolicy 애노테이션 생성
8. List, Map : 조회한 빈이 모두 필요 할 때
- 적으로 특정 타입의 스프링 빈이 필요한 경우가 있음
예) 할인 서비스를 제공 : 클라이언트가 할인의 종류(rate, fix)를 선택 가능 -> 스프링을 통해 전략 패턴을 간단하게 구현
