의존관계 자동 주입

다양한 의존관계 주입 방법

---

의존관계 주입 방법

1. 생성자 주입
2. 수정자 주입
3. 필드 주입
4. 일반 메서드 주입

생성자 주입

• 생성자를 통해 의존 관계 주입
• 생성자 호출 시점에 딱 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;
      }
}

수정자 주입

• 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;
	}
}

• @Autowired는 기본적으로 주입할 대상이 없으면 오류 발생
  • 주입할 대상이 없어도 동작하게 하려면 Autowired(required = false)로 설정

필드 주입

• 필드에 바로 의존관계 주입
• 코드가 간결하다는 장점이 있지만, 외부에서 변경이 불가능해 테스트가 어렵다는 단점이 존재
  • DI 프레임워크가 없다면 아무것도 할 수 없다
• 스프링 설정을 목적으로 하는 @Configuration 같은 곳 외에는 사용 권장 X

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired
    private MemberRepository memberRepository;

    @Autowired
    private DiscountPolicy discountPolicy;
}

일반 메서드 주입

• 일반 메서드를 통해 의존관계 주입
• 한번에 여러 필드를 주입 받을 수 있다는 장점이 있다

@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(required = false) : 주입 대상이 없으면, 수정자 메서드 자체가 호출 안 됨
• org.springframework.lang.@Nullable : 주입 대상이 없으면, null이 입력 됨
• Optional<> : 주입 대상이 없으면, Optional.Empty가 입력 됨

//호출 안됨    
@Autowired(required = false)
public void setNoBean1(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);
}

 

생성자 주입을 선택

---

최근에는 대부분 생성자 주입을 권장

불변

• 대부분의 의존관계는 종료시점까지 변경될 일이 없다
• 수정자 주입 등을 사용하면 setter가 public으로 열려있으므로, 누군가 실수로 변경할 수도 있다
• 생성자 주입은 객체를 생성할 때 딱 1번만 호출됨이 보장되므로, 불변을 보장

누락

• 객체 생성 시에 반드시 의존 관계를 주입해야 하기 때문에, 테스트 코드 등의 코드를 작성할 때 의존관계 설정을 하기 쉽다.
• IDE에서 객체 생성 시 의존 관계를 주입하지 않으면 컴파일 오류가 발생하기 때문

final 키워드

• 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다.
• 생성자에서 값이 설정되지 않는다면 컴파일 시점에서 오류를 체크할 수 있다.
• 오직 생성자 주입 방식에서만 final 키워드를 사용할 수 있다.

 

롬복과 최신 트랜드

---

기본 코드

@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;
  }
}

@Autowired 생략

• 생성자가 1개만 있으면 @Autowired를 생략할 수 있다.

@Component
public class OrderServiceImpl implements OrderService {
  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;

  public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
  }
}

@RequiredArgsConstructor

• lombok에서 지원하는 어노테이션으로, final이 붙은 필드를 모아 생성자를 자동으로 만들어 준다.

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;
}

 

@Autowired 필드명, @Qualifier, @Primary

---

조회 빈이 2개 이상일 때 해결 방법

1. @Autowired 필드 명 매칭
2. @Qualifier끼리 매칭
3. @Primary 사용

@Autowired 필드명 매칭

• @Autowired는 기본적으로 타입 매칭을 시도
• 이 때, 여러 빈이 존재하면, 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭

// NoUniqueBeanDefinitionException 에러 발생
@Autowired
private DiscountPolicy discountPolicy

// 해결법
@Autowired
private DiscountPolicy

• DiscountPolicy가 여러개가 있으므로, 필드명(rateDiscountPolicy)으로 빈을 재검색 후 존재하면 주입

@Qualifier

• 빈 등록 시 해당 어노테이션을 붙여 준다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy{}

@Component
@Qualifier("subDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy{}

• 주입 시에도 @Qualifier 어노테이션을 통해 빈을 주입 받는다.

public class OrderServiceImpl implements OrderService{

	@Autowired
	public OrderServiceImpl(
		MemberRepository memberRepository,
		**@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy**){
		this.memberRepository = memberRepository
		this.discountPolicy = discountPolicy
	}
}

qualifier의 이름을 못 찾는 경우에는 해당 이름의 스프링 빈을 추가로 찾지만 권장 X

1. @Qualifier끼리 매칭
2. 빈 이름 매칭
3. NoSuchBeanDefinitionException 예외 발생

@Primary

빈의 우선순위를 정해준다.

• @Autowired 시 여러 빈이 매칭되면, @Primary가 우선권을 가진다.

@Component
**@Primary // 우선권을 가짐!**
public class RateDiscountPolicy implements DiscountPolicy{}

@Component
public class FixDiscountPolicy implements DiscountPolicy{}

@Primary와 @Qualifier 활용

• 코드에서 주로 사용하는 빈 : @Primary로 지정해 기본값으로 빈을 주입받을 수 있도록 함
• 특별한 기능으로 가끔 사용하는 빈 : @Qualifier를 지정해, 특정 경우에만 빈을 주입받도록 함

@Component
@Primary
public class MainDB{}

@Component
@Qualifier("{feat}DB")
public class SubDB{}

우선순위

• @Qualifer > @Primary

 

어노테이션 직접 만들기

---

기존 @Qualifier 문제점

• @Qualifier("mainDiscountPolicy")와 같이 사용하는 경우, 컴파일 시 타입 체크가 안 되는 문제가 존재

public class OrderServiceImpl implements OrderService{

	@Autowired
	public OrderServiceImpl(
		MemberRepository memberRepository,
		**@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy**){
		this.memberRepository = memberRepository
		this.discountPolicy = discountPolicy
	}
}

• 어노테이션을 만들어 위 문제를 해결할 수 있다.

어노테이션 만들기

@Target({ElementType.FILED, ElementType.METHOD, ElementType.PARAMETER,
				 ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy{}

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy{}

public class OrderServiceImpl implements OrderService{

	@Autowired
	public OrderServiceImpl(
		MemberRepository memberRepository,
		@MainDiscountPolicy DiscountPolicy discountPolicy){
		this.memberRepository = memberRepository
		this.discountPolicy = discountPolicy
	}
}

 

조회한 빈이 모두 필요할 때, List, Map

---

특정 타입의 빈이 모두 필요한 경우도 존재

• 할인 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택하는 경우, 서버에서 모든 할인 서비스 빈을 갖고 있어야 한다.

리스트로 받는 경우

class DiscountPolicy{
	private final List<DiscountPolicy> policies;
	
	@Autowired
	public DiscountPolicy(List<DiscountPolicy> policies){
		this.policies = policies
	}
}

• List로 빈 주입을 받으면 스프링에서 자동으로 해당 타입의 빈을 모두 찾아 리스트로 반환

맵으로 받는 경우

class DiscountPolicy{
	private final Map<String, DiscountPolicy> policyMap;

	public DiscountPolicy(Map<String, DiscountPolicy> policyMap){
		this.policyMap = policyMap
	}
}

• map<String, Type>으로 빈 주입을 받으면 스프링에서 자동으로 해당 타입의 빈을 모두 찾아 맵으로 반환
• 이 때 맵의 key는 빈의 이름이다.

 

자동, 수동의 올바른 실무 운영 기준

---

최근에는 대부분 자동 빈 등록을 사용

• @component, @Service, @Repository, @Controller 등을 사용

수동 빈을 사용하는 경우

• 어플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해 설정 정보에 바로 나타나게 하는 것이 유지보수에 좋다.
• 다형성을 활용하는 비즈니스 로직은 수동 등록을 고민
  • 위의 DiscountPolicy에서는 policyMap이나 policies와 같이 다양한 Policy를 받아 처리
  • 위 코드에서 어떤 policy들을 주입받는지를 알기가 어렵다.
  • DiscountPolicy를 별도 설정 파일에 수동 빈 등록을 해놓으면 알아보기가 쉽다.

@Configuration
public class DiscountPolicyConfig{
	@Bean
	public DiscountPolicy rateDiscountPolicy(){
		return new RateDiscountPolicy();
	}

	@Bean
	public DiscountPolicy fixDiscountPolicy(){
		return new FixDiscountPolicy();
	}
}