[ 스프링 핵심원리 - 기본편 ] 의존관계 자동 주입

다양한 의존관계 주입 방법

• 생성자 주입
• 수정자 주입 ( setter 주입 )
• 필드 주입
• 일반 메서드 주입

생성자 주입

생성자를 통해서 의존 관계를 주입 받는 방법

지금까지 했던 방법

특징

• 생성자 호출 시점에 딱 1번만 호출되는 것이 보장
• 불변, 필수 의존관계에 사용

//OrderServiceImpl.jav

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

    }
}

• MemberRepository, DiscountPolicy 변경 불가 (불변)
• 생성자 호출할 때 MemberRepository, DiscountPolicy 필수로 넘겨주어야 함 (필수)

< 중요! > 생성자가 하나일 경우는 @Autowired를 생략해도 자동 주입 된다.

수정자 주입

setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법

특징

• 변경,선택 가능성이 있는 의존관계에서 사용
• 자바빈 프로퍼티 규약의 수정자 메서드를 사용하는 방법

//OrderServiceImpl.java

@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(required = false)
    public void setMemberRepository(MemberRepository memberRepository) {
        
        this.memberRepository = memberRepository;
    }

• @Autowired의 기본 동작은 주입할 대상이 없으면 오류가 발생한다.
  • (required = false)를 추가함으로써 memberRepository는 필수값이 아니게 됨 ( 선택 )

참고: 자바빈 프로퍼티: 자바에서는 과거부터 필드의 값을 직접 변경하지 않고 setXxx, getXxx 라는 메서드를 통해서 값을 읽거나 수정하는 규칙을 만들었는데, 이것이 자바빈 프로퍼티 규약이다.

• 프로퍼티 값을 구하는 메소드는 get으로 시작한다.
• 프로퍼티 값을 변경하는 메소드는 set으로 시작한다.
• get과 set 뒤 첫 글자는 대문자로 바꾼다.

필드 주입

필드에 바로 주입하는 방법

특징

• 코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트하기 힘들다는 치명적인 단점이 있다.
• DI 프레임워크가 없으면 아무것도 할 수 없다.
  • 순수한 테스트를 만들 수 없음. 값을 넣어줄 때 따로 setter를 만들어 주입을 해줘야하는데, 그렇게 setter가 만들어지면 그냥 수정자 주입과 다를 바가 없다.

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

• 가급적 사용하지않는게 좋지만 사용할 수 있는 경우가 있다.
  • 테스트 코드
  • 스프링 설정을 목적으로 하는 @Configuration 같은 곳

일반 메서드 주입

일반 메서드를 통한 주입

특징

• 한번에 여러 필드를 주입 받을 수 있다.
• 일반적으로 잘 사용하지는 않는다.
  • 생성자 주입, 수정자 주입으로 다 해결되기 때문

//OrderServiceImpl.java

@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 코드를 적용해도 아무 기능도 동작하지 않는다.

 

 

옵션 처리

주입할 스프링 빈이 없어도 동작해야할 때가 있다.

자동 주입 대상을 옵션으로 처리하는 방법

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

package hello.core.autowired;

import hello.core.member.Member;
import jakarta.annotation.Nullable;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.web.reactive.context.AnnotationConfigReactiveWebApplicationContext;
import org.springframework.context.ApplicationContext;

import java.util.Optional;

public class AutowiredTest {

    @Test
    void AutowiredOption(){
        ApplicationContext ac = new AnnotationConfigReactiveWebApplicationContext(TestBean.class);

    }

    static class TestBean{

        @Autowired(required = false)
        public void setNoBean1(Member noBean1){
            System.out.println("noBean1 = " + noBean1);
        }

        @Autowired
        public void setNoBean2( @Nullable Member noBean2){
            System.out.println("noBean2 = " + noBean2);
        }

        @Autowired
        public void setNoBean3(Optional<Member> noBean3){
            System.out.println("noBean3 = " + noBean3);
        }

    }
}

실행 결과

• member는 스프링 빈이 아니다.
• setNoBean1은 @Autowired(required = false) 이므로 호출 자체가 안된다

참고: @Nullable, Optional은 스프링 전반에 걸쳐서 지원된다. 예를 들어 생성자 자동 주입에서 특정 필드에 사용해도 된다.

생성자 주입을 선택하라

불변

• 대부분의 의존관계 주입은 한번 일어난 후 종료시점까지 의존관계를 변경할 일이 없다.
• 수정자 주입을 이용하면 setXxx메서드를 public으로 열어두어야하는데, 이 때문에 누군가 실수로 변경할 가능성이 생긴다.

→ 생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 불변하게 설계 가능하다.

누락

프레임워크 없이 순수한 자바 코드로 단위 테스트를 하는 경우

//OrderServiceImpl.java

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@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
    public OrderServiceImpl(MemberRepository memberRepository,DiscountPolicy discountPolicy) {
        this.memberRepository=memberRepository;
        this.discountPolicy = discountPolicy;

    }*/

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member,itemPrice);

        return new Order(memberId,itemName,itemPrice,discountPrice);
    }

    //테스트 용도
    public MemberRepository getMemberRepository() {
        return memberRepository;
    }
}

//OrderServiceImplTest.java

package hello.core.order;

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class OrderServiceImplTest {

    @Test
    void createOrder(){
        OrderServiceImpl orderService = new OrderServiceImpl();
        orderService.createOrder(1L,"itemA",10000);

    }

}

해당 테스트 코드를 실행하면 NullPointerException에러가 뜬다

→ memberRepository, discountPolicy 모두 의존관계 주입이 누락되었기 때문

//OrderServiceImplTest.java

package hello.core.order;

import hello.core.discount.FixDiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import hello.core.member.MemoryMemberRepository;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.*;

class OrderServiceImplTest {

    @Test
    void createOrder(){
        MemberRepository memberRepository = new MemoryMemberRepository();
        memberRepository.save(new Member(1L, "catsbi", Grade.VIP));

        OrderServiceImpl orderService = new OrderServiceImpl();
        orderService.setMemberRepository(memberRepository);
        orderService.setDiscountPolicy(new FixDiscountPolicy());

        Order order = orderService.createOrder(1L, "itemA", 10000);

        assertThat(order.getDiscountPrice()).isEqualTo(1000);

    }

}

위와 같이 코드를 수정해주어야 정상적으로 동작함

수정자 주입의 경우 누락된 데이터가 무엇인지 코드를 보며 일일이 찾아보며 수정해주어야한다.

final 키워드

생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다.

→ 생성자에서 값이 설정되지 않는 경우, 해당 오류를 컴파일 시점에 막아준다.

 

 

기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여할 수 있다. (생성자 주입과 수정자 주입을 동시에 사용할 수 있음)

 

롬복과 최신 트렌드

생성자 주입을 사용하면 생성자도 만들어야 하고, 주입 받은 값을 대입하는 코드도 만들어야 하는 번거로움이 생긴다.

→ 롬복을 통해 이 번거로움을 줄일 수 있다.

start.spring.io에서 초기 프로젝트를 생성할 때 롬복을 추가해줄 수 있지만 우리는 프로젝트 생성 시 롬복을 추가하지 않았으므로 build.gradle 에 아래와 같이 코드를 추가해준다.

plugins {
	id 'java'
	id 'org.springframework.boot' version '3.0.6'
	id 'io.spring.dependency-management' version '1.1.0'
}

group = 'hello'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'
//lombok 설정 추가 시작

configurations {
	compileOnly {
		extendsFrom annotationProcessor
	}
}
//lombok 설정 추가 끝
repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'

	//lombok 라이브러리 추가 시작
	compileOnly 'org.projectlombok:lombok'
	annotationProcessor 'org.projectlombok:lombok'
	testCompileOnly 'org.projectlombok:lombok'
	testAnnotationProcessor 'org.projectlombok:lombok'
	//lombok 라이브러리 추가 끝
}

tasks.named('test') {
	useJUnitPlatform()
}

코드 추가 후 우측상단에 코끼리 모양을 눌러주면 새롭게 추가한 롬복 라이브러리가 적용된다.

추가적으로 IntelliJ IDEA > settings 에서 Annotation Processors를 찾아 Enable annotation processing을 체크해준다

 

롬복 적용 후 코드

@Component
@RequiredArgsConstructor
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 : final이 붙은 필드들을 모아 생성자를 자동으로 생성해줌. 

 

 

 

 

조회 빈이 2개 이상 - 문제

@Autowired는 타입으로 조회한다.

DiscountPolicy 의 하위 타입인 FixDiscountPolicy , RateDiscountPolicy 둘다 스프링 빈으로 선언할 경우 문제가 발생한다.

실행해보면 하나의 빈을 기대했는데 ‘fixDiscountPolicy’ , ‘rateDiscountPolicy’ 2개가 발견되었다는 오류메시지가 뜬다.

 

이 문제를 해결하기 위해 매번 하위 타입을 지정하는 것은 DIP를 위배하고 유연성이 떨어진다.

어떻게 해결할 수 있을까?

 

@Autowired 필드명, @Qualifier, @Primary

앞서 언급한 문제를 해결할 수 있는 방법을 알아보자.

• @Autowired 필드 명 매칭
• @Qualifier @Qualifier끼리 매칭 빈 이름 매칭
• @Primary 사용

@Autowired 필드 명 매칭

@Autowired는 타입 매칭을 시도하고, 이 때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

//기존 코드
@Autowired
  private DiscountPolicy discountPolicy

//필드명을 빈 이름으로 수정한 코드
@Autowired
  private DiscountPolicy rateDiscountPolicy

필드 명을 ‘rateDiscountPolicy’로 지정하여 오류 없이 정상 주입 된다.

@Autowired는 먼저 타입 매칭을 시도하고, 그 결과 여러 빈이 있을 때 필드 명, 파라미터 명 으로 빈 이름을 매칭한다.

@Qualifier 사용

@Qualifier는 추가 구분자를 붙여준느 방법이다. 빈 이름을 변경하는 것이 아닌 추가적인 방법을 통한 주입이다.

빈 등록시 @Qualifier를 붙여준다.

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

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

생성자 자동 주입 예시

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

@Qualifier 로 주입할 때 @Qualifier("mainDiscountPolicy") 를 못찾으면 ‘mainDiscountPolicy’라는 이름의 스프링 빈을 추가로 찾는다. 하지만 @Qualifier는 @Qualifier 를 찾는 용도로만 사용하는게 명확하고 좋다

@Qualifier는 먼저 @Qualifier끼리 매칭을 시도하고, 없을 경우 빈 이름을 매칭한다. 매칭되는 빈을 찾지 못한다면 NoSuchBeanDefinitionException 예외가 발생한다.

@Primary

@primary는 우선순위를 지정하는 방법이다.

아래와 같이 @Primary를 붙여주게 되면 rateDiscountPolicy가 fixDiscountPolicy보다 우선순위를 갖게 된다.

@Component
  @Primary
  public class RateDiscountPolicy implements DiscountPolicy {}

@Qualifier의 경우 주입 받을 때 모든 코드에 @Qualifier를 붙어주어야 한다는 단점이 있다. 반면에 @Primary는 @Qualifier처럼 모든 코드에 애노테이션을 붙이지 않아도 된다는 장점이 있다.

@Primary와 @Qualifier의 우선 순위

@Primary는 기본값 처럼 동작하는 것이고, @Qualifier는 매우 상세하게 동작한다. 스프링은 자동보다는 수동이, 넓은 범위의 선택권보다는 좁은 범위의 선택권이 우선순위가 높다. 따라서 @Qualifier가 우선순위가 더 높다.

 

 

애노테이션 직접 만들기

@Qualifier("mainDiscountPolicy") 처럼 문자를 적으면 컴파일시 타입 체크가 안된다. 즉, @Qualifier("mmainDiscountPolicy")와 같이 오타가 발생해도 동작한다.

다음과 같이 애노테이션을 만들어서 문제를 해결할 수 있다.

package hello.core.annotation;

import org.springframework.beans.factory.annotation.Qualifier;

import java.lang.annotation.*;

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

package hello.core.discount;

import hello.core.annotation.MainDiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Primary;
import org.springframework.stereotype.Component;

@Component
//@Qualifier("mainDiscountPolicy")
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy{
    private int discountPercent =10;
    @Override
    public int discount(Member member, int price) {
        if(member.getGrade() == Grade.VIP){
            return price * discountPercent /100 ;
        }else{
            return 0;
        }

    }
}

//OrderServiceImpl.java

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

    }

애노테이션에는 상속이라는 개념이 없다.이렇게 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능이다. @Qualifier뿐만 아니라 다른 애노테이션들도 함께 조합해서 사용할 수 있다.

 

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

지금까지는 자동주입하기위해 스프링 빈 검색해서 2개 이상 나오는 경우 하나를 골라서 주입하는 방법에 대해 알아보았다. 이번에는 2개 이상의 스프링 빈을 모두 조회해야하는 경우를 살펴보자.

예를 들어, 소비자가 rateDiscountPolicy와 fixDiscountPolicy 중 선택할 수 있다고 가정해보자.

package hello.core.autowired;

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import java.util.List;
import java.util.Map;

import static org.assertj.core.api.Assertions.*;

public class AllBeanTest {

    @Test
    void findAllBean(){
        ApplicationContext ac = new
                AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        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);
    }
    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;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }

    }
}

로직 분석

DiscountService는 Map으로 모든 DiscountPolicy 를 주입받는다. 이때 fixDiscountPolicy , rateDiscountPolicy 가 주입된다.

discount () 메서드는 discountCode로 "fixDiscountPolicy"가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아서 실행한다. 물론 “rateDiscountPolicy”가 넘어오면 rateDiscountPolicy 스프링 빈을 찾아서 실행한다.

주입 분석

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다. 만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다.

 

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

“편리한 자동 기능을 기본으로 사용하자”

수동 빈 등록은 언제 사용하면 좋을까?

• 업무 로직 빈: 비즈니스 요구사항들을 개발할 때 추가되거나 변경된다. → 자동 기능 적극 사용
• 기술 지원 빈: 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들 → 수동 빈 등록을 사용

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 딱! 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋다.

비즈니스 로직 중에서 다형성을 적극 활용하는 경우

DiscountService 가 의존관계 자동 주입으로 Map<String, DiscountPolicy> 에 주입을 받는 상황을 생각해보자. 여기에 어떤 빈들이 주입될 지, 각 빈들의 이름은 무엇일지 코드만 보고 한번에 쉽게 파악할 수 있을까?

→ 수동 빈으로 등록하거나, 자동으로 할 경우 특정 패키지에 같이 묶어 두는 것이 좋다.