김영한 (스프링 핵심 원리 7) 의존관계 자동 주입

다양한 의존관계 주입 방법

스프링 빈을 등록을 하는 단계와 의존관계를 주입하는 단계가 따로 되어있다.

생성자 주입 

생성자 호출시점에 딱 1번만 호출되는것이 보장된다. 불변,필수 의존관계에 사용한다. 좋은 코딩 습관은 항상 제약이 있는 것이 좋다. 

private final 은 값이 무조건 있어야 된다는 뜻이다. 언어적으로 잡은것이다. 안주면 컴파일 에러를 동반한다. 

 

수정자 주입(setter 주입)

관례로 field 값을 조정할때 set을 많이 사용한다.  

선택, 변경 가능성이 있는 의존관계에 사용

 

필드주입

코드가 간결해서 많은 개발자들을 유혹하지만 외부에서 변경이 불가능해서 테스트하기 힘들다는 치명적인 단점

DI 프레임워크가 없으면 아무것도 못함 사용하지말자

@Configuration 같은 곳에서만 특별한 용도로 사용 , Test 코드에서도 사용가능 왜냐하면 아무도 가져다 쓸일이 없으니까

 

일반메서드 주입

한번에 여러 필드를 주입 받을 수 있다. 아무 메서드에다 @Autowired를 붙여서 쓸 수 있기 때문이다.  

잘 사용하지 않음 

 

옵션처리

@Autowired의 required 옵션값은 기본으로 True 이다. 

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

여기서 Member 는 스프링 Bean이 아니라 순수한 자바 객체이다. 자동주입을 할 빈이 없으므로 이 메소드 호출 자체가 안된다. 

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

아무리 자동주입할 빈이 없다 하더라도 호출이 되길 원하면 @Nullable을 쓰면 호출이되면서 Null이 들어온다.

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

빈이 없을 경우 Optional.empty , 값이 있으면 Optional로 감싸져서 나온다.

 

생성자 주입이 좋은이유

불변

대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.

수정자 주입을 사용하면, setXxx 메서드를 public 으로 열어두 어야한다.(안좋음 , 누군가가 호출해서 바꿔버릴수도있음)

생성자 주입은 객체를 생성할 때 딱 1번만 호출이 되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

final 키워드를 사용할 수 있다. 

누락

프레임워크 없이 순수한 자바코드를 단위 테스트 하는 경우 setter의 경우는 컴파일 오류를 띄우지 않는다. 생성자의 경우에는 컴파일에러를 띄워준다.

 

롬복과 최신 트렌드

자바의 annotation Processor를 설정해주어야한다.

package hello.core;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;


@Getter
@Setter
@ToString
public class HelloLombok
{
    private String name;
    private int age;

    public static void main(String[] args)
    {
        HelloLombok helloLombok = new HelloLombok();
        helloLombok.setName("tonynubmer ");
    }
}

lombok을 이용하면 직접 setter getter tostring 메소드를 구현하지않고 만들어준다.

package hello.core.order;

import hello.core.discount.DiscountPolicy;
import hello.core.member.Member;
import hello.core.member.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Component;


@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService
{
    private final MemberRepository memberRepository;
    private final 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;
    }
}

생성자 주입할 때도 생성자를 아예 @RequiredArgsConstructor 로 만들어준다. 호출도 가능하다. 완전히 동일하다고 볼수있다.

 

조회할 빈이 2개 이상일때 

이름만 다르고 타입이 똑같은 빈이 여러개 있을 때의 해결방법

 

@Autowired를 사용한 경우 생성자의 인자의 이름으로 매핑이 되는 경우를 이용할 수 있다. 

타입으로 매칭되는게 여러 개 있을 경우 , 이름으로 한번 찾아보기 때문이다.

@Qualifer 를 사용한다. @Qualifer("mainDiscountPolicy") 를 생성자의 인자와 해당 객체에 써준다.

@Primary를 사용한다. 우선순위를 정하는 방법이다. @Autowired 시에 여러 빈 매칭되면 @Primary가 우선권을 가진다.

 

애노테이션 직접 만들기

@Qualifer("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일시 타입 체크가 안된다 오타 또한 문제가 될 수 있다. 다음과 같은 애노테이션을 만들어서 문제를 해결할 수 있다.

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)
@Inherited
@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.stereotype.Component;

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy
{
    private int discountPrecent = 10;

    @Override
    public int discount(Member member, int price)
    {
        if (member.getGrade() == Grade.VIP)
        {
            return price * discountPrecent / 100;
        }
        else
        {
            return 0;
        }
    }
}

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

이런식으로 애노테이션을 만들어서 쓰면 오타나 타입을 컴파일오류로 발견할 수 있다. 

 

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

의도적으로 정말 해당타입의 스프링 빈이 다 필요한 경우도 있다.

예를 들어서 할인 서비스를 제공하는데, 클라이언트가 할인의 종류(rate,fix)를 선택할 수 가 있다.

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.beans.factory.annotation.Autowired;
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> polices;

        @Autowired
        DiscountService(Map<String, DiscountPolicy> policyMap, List<DiscountPolicy> polices)
        {
            this.policyMap = policyMap;
            this.polices = polices;
            System.out.println("policyMap = " + policyMap);
            System.out.println("polices = " + polices);
        }

        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과 list에 해당되는 타입(DiscountPolicy) 들을 모두 받아옵니다. 

findAllBean() 테스트 메소드에서는 AutoAppConfig안에 들어있는 @ComponentScan을 통해 DiscountPolicy 들의 객체들을 Bean으로 등록을 시켜 줍니다. 

아래에 만든 discount 메소드를 호출시켜서 테스트를 해줍니다.

 

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

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

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

업무 로직 빈 = 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.

기술 지원 빈 = 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그처리 업무 로직을 지원하기 위한 하부 기술이나 공통 기술이다.

업무로직은 숫자도 매우 많고 유사한 패턴이 존재함으로 자동 기능을 사용하는 것이 좋다.

기술 지원 로직은 상대적으로 수가 매우적고 , 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많다. 그래서 수동 빈등록을 사용해서 명확하게 들어내는 것이 좋다.