의존 관계 자동 주입

다양한 의존 관계 주입 방법

생성자 주입

• 생성자를 통해 의존 관계를 주입 받는 방법
• 특징
  • 생성자 호출 시점에 딱 1번만 호출 되는 것이 보장
  • 불편, 필수 의존 관계에 사용
• 생성자가 딱 1개만 있으면 @Autowired를 생략 해도 자동 주입이 됨

수정자(setter) 주입

• setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해 의존 관계를 주입하는 방법
• 특징
  • 선택, 변경 가능성이 있는 의존 관계에 사용
  • 자바빈 프로터피 규약의 수정자 메서드 방식을 사용하는 방법

필드 주입

• 필드에 바로 주입하는 방법
• 특징
  • 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 있음
  • DI 프레임워크가 없으면 아무것도 할 수 없음
  • 사용하지 말자

일반 메서드 주입

• 일반 메서드를 통해 주입 받을 수 있음
• 특징
  • 한번에 여러 필드를 주입 받을 수 있음
  • 일반적으로 잘 사용하지 않음

옵션 처리

Autowired만 사용하면 required 옵션의 기본값이 true로 되어 있어서 자동 주입 대상이 없으면 오류가 발생합니다.

• Autowired(required = false): 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
• org.springframework.lang.@Nullable: 자동 주입할 대상이 없으면 null이 입력 됨
• Optional<>: 자동 주입할 대상이 없으면 Optional.empty가 입력 됨

생성자 주입을 선택해라

불변

• 대부분의 의존 관계는 한 번 일어나면 어플리케이션 종료시점까지 의존 관계를 변경할 일이 없음. 오히려 대부분의 의존 관계는 어플리케이션 종료 전까지 변하면 안 됨
• 수정자 주입을 사용하면 setXxx 메서드를 public로 열어두어야 함
• 누군가 실수로 변경할 수도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아님
• 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있음

누락

• 생성자 주입을 사용하면 주입 데이터를 누락 했을 때 컴파일 오류가 발생 함

final 키워드

• 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있음
• 그래서 생성자에서 혹시라도 값이 설정되지 않는 오류를 컴파일 시점에 막아 줌

롬복과 최신 트랜드

• @RequiredArgsConstructor: final이 붙은 필드를 생성자로 만들어 줌

롬복 라이브러리 적용

• build.gradle

dependencies {
  // ...

  // 롬복 라이브러리 추가
  compileOnly("org.projectlombok:lombok")
  annotationProcessor("org.projectlombok:lombok")

  testCompileOnly("org.projectlombok:lombok")
  testAnnotationProcessor("org.projectlombok:lombok")

}

사용법

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {

  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;
}

조회 빈이 2개 이상일 때

@Component
public class FixDiscountPolicy implements DiscountPolicy {
}

@Component
public class RateDiscountPolicy implements DiscountPolicy {
}

@Autowired
private DiscountPolicy discountPolicy;

• 위 처럼 설정하면 NoUniqueBeanDefinitionException오류가 발생함

Autowired 필드 명, @Qualifier, @Primary

Autowired 필드 명 매칭

• 타입 매칭
• 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

@Autowired
private DiscountPolicy rateDiscountPolicy;

• 위 처럼 하면 RateDiscountPolicy가 주입됩니다.

Qualifier 사용

• @Qualifier끼리 매칭
• 빈 이름 매칭
• NoSuchBeanDefinitionException 예외 발생

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

@Component
public class OrderServiceImpl implements OrderService {

  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;

  public OrderServiceImpl(MemberRepository memberRepository, @Qualifier("fixDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
  }
}

Primary 사용

• @Primary가 우선권을 가짐

@Component
@Primary
public class FixDiscountPolicy implements DiscountPolicy {
}

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

@Primary, @Qualifier 우선순위

• @Qualifier이 더 좁은 범위의 선택권이므로 우선권이 높음

어노테이션 직접 만들기

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

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {
}

@Component
public class OrderServiceImpl implements OrderService {

  private final MemberRepository memberRepository;
  private final DiscountPolicy discountPolicy;

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

여러 어노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능입니다.

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

예를 들어 할인 서비스를 제공하는데, 클라이언트가 할인의 종류를 선택할 수 있다고 가정해보겠습니다. 스프링을 사용하면 전략 패턴을 매우 간단하게 구현할 수 있습니다.

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;
    this.policies = policies;
  }

  public int discount(Member member, int price, String discountCode) {
    return policyMap.get(discountCode).discount(member, price);
  }
}

DiscountPolicy 전체 빈을 주입 받아, discountCode로 해당 DiscountPolicy를 찾아 할인을 처리하도록 한 것입니다.

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

• 편리한 자동 기능을 기본으로 사용
• 직접 등록하는 기술 지원 객체는 수동 등록
• 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자
  • 자동 등록 시, 패키지라도 묶어야 함

• 업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등
• 기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 떄 주로 사용. DB 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술

참고

• https://www.inflearn.com/course/스프링-핵심-원리-기본편