[Spring] 김영한 기본편_ 섹션 8. 의존관계 자동 주입

<출처 인프런>

 

코로나에 걸려 일주일은 누워있다 살아났다. 먹고 자고만 반복하니 나태함의 끝판왕이 되어버렸는데... 이렇게 다시 공부를 하려니 배로 힘든 것 같다. 8월엔 꼭 강의를 다 듣겠다고 다짐했었는데,,, 얼마 남지 않은 시간 다른 공부 제처두고 8월 안에 끝내볼까 한다. (과연 할 수 있으려나?) 아무튼 모두들 화이팅!!!!

🧸 

 

---

 

🧸 구조파악 레츠꼬우- 🧸

 • order

ㄴ class : OrderServiceImpl

 • annotation

ㄴ interface : MainDiscountPolicy

 • HelloLombok

 

 • AllBeanTest

ㄴ class : AllBeanTest

 • AutoWiredTest

ㄴ class : AutoWiredTest

---

 

✔️  OrderServiceImpl

 

►  생성자 주입

지금까지 사용한 방법이 되겠다.

 

private final MemberRepository memberRepository;
private final DiscountPolicy discountPolicy;

     

final

: 초기화되면 변경할 수 없게 된다. 

 

 

final을 통해 생성자에 값이 제대로 설정되지 않으면 컴파일 오류를 발생시킬 수 있다. 컴파일 오류를 통해 생성자에 값을 빼먹은 걸 빠르게 알아차릴 수 있다. 그렇기에 생성자 주입 방법을 추천한다.

 

 

Q. final을 안쓰게 된다면 어떻게 되나?

A. 코드 개발이 한사람으로 이뤄지는게 아니기 때문에, 다른 개발자가 코드를 수정하게되면 오류가 발생할 수 있다. 거기다 생성자를 만들지 않으면 테스트가 돌아가지 않기 때문에 오류 수정에 용이하다. 생성자 주입에서 final을 붙여야만 코드가 돌아가는 것은 아니다. (근데 그렇데되면 생성자 코드라고 부르기 어렵지 않을까..?)

 

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

 

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

 

 

@Autowired

: 의존관계를 주입해주는데, 생성자가 하나인 경우는 사용하지 않아도 자동적으로 주입이 된다.

 

 

OrderServiceImpl은 클래스  MemberRepository와 DiscountPolicy에 있는 memberRepository와 discountPolicy를 필요로 한다. 그렇기에 생성자(객체를 초기화하는 특별한 메서드)를 만들어 그 생성자가 다른 클래스의 객체를 할당받을 수 있도록 의존관계 주입이 이뤄지게 된다.

예를 들어보면, 계산을 해야하는 메서드가 있다고 가정해보자. 계산 메서드에는 회원 정보와 현재 할인 정책에 대한 정보를 필요로 한다. 그 두가지의 정보를 가져오기 위해 회원 정보와 할인 정책 정보를 가지고 있는 클래스가 필요한 것이다. 그래서 의존관계 주입을 통해 현재 클래스와 다른 두 클래스의 정보를 가져오도록 하는 것이다.

(이렇게 이해하긴 했다...)

 

 

 

 

 

 

►  수정자 주입

setter로 통해 의존관계 주입, 의존관계를 누락해도 실행은 된다.

 

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }

 

 

setter는 @Autowired를 사용하여 의존관계를 받게된다. 그러면 각 클래스인 MemberRepository와 DiscountPolicy에서 memberRepository와 discountPolicy에 대한 의존관계를 받는 것이다. 그렇게 객체를 final 없이 선언할 때 객체의 상태 변경을 할 수 있게 된다.

생성자 주입에서는 final을 통해 값을 변경할 수 없도록 했지만 setter는 final이 없기 때문에 객체의 상태에 변경이 가능하다. setter는 설정하려는 필드와 동일한 타입의 매개변수를 받아야하며, 자바빈 프로퍼티 규약을 통해 set---라고 메서드를 통해 정보를 수정하는 규칙이 생겼다. 

 

 

- setter를 통해 객체 상태 바꾸기 출처

[JAVA] 게터(getter)와 세터(setter)

 

 

 

 

Q. 생성자는 매개변수를 여러개 받을 수 있었다. setter는 하나의 매개변수만 받았다. 왜 그런것인가?

A. 생성자는 객체를 생성할 때 필요한 모든 필드에 대해 값을 주입하는 역할을 한다. ( 값을 받아서 객체를 사용하는 필드에 넣어준다는 것 같다.) 그런데 setter는 객체 상태에 수정이 들어가니 주로 하나의 매개변수만 사용한다. 꼭 setter를 사용할 때 하나의 매개변수만 사용가능한 것은 아니지만 나중에 유지보수를 생각해서 하나씩 사용한다고 한다. 실제로 setter는 사용을 지양하는 추세라고 한다. 이건 전에도 다룬적이 있던 것 같은데, 객체의 상태를 test 코드 혹은 현재 setter 코드 등에서 값을 변경할 수 있기 때문에 오류가 발생할 확률이 높기 때문이다.  

 

 

 

 

 

 

►  필드 주입

필드에 바로 의존관계 주입 (사용하지말자)

 

 

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private DiscountPolicy discountPolicy;

 

OrderServiceImpl에 각 클래스 MemberRepository와 DiscountPolicy에 관한 의존관계 주입이 바로 이뤄진다.

 

 

 

 

 

---

 

 

 

 

✔️  AutowiredTest

 

@Test
void AutoWiredOption() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
}

 

 

AnnotationConfigApplicationContext

:  스프링 컨테이너를 생성하며, 빈을 관리하고 의존성 주입을 처리한다.

 

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

 

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 setBean3(Optional<Member> nobean3) {
        System.out.println("nobean3 = " + nobean3);
    }


}

 

@Autowired(required = false)

: 자동 주입할 대상이 없으면 수정자 메서드가 없으면 호출 자체가 안된다.

 

 

@Nullable

: 자동 주입할 대상이 없어도 호출은 되지만 null값이 된다.

 

 

Optional< >

: 스프링 빈이 없으면 Optional empty로 들어온다.

 

 

현재 Member 클래스에는 nobean1, nobean2, nobean3과 관련된 bean이 등록되어있지 않기에 오류가 발생할 수 있다. 하지만 각 코드를 추가하여 오류가 발생하는 것을 방지한다. nobean1의 required = true로 하게되면 오류가 발생하게된다. 

 

 

 

Q. AnnotationConfigApplicationContext를 선언을 따로하는 이유는 무엇일까?

A. AnnotationConfigApplicationContext가 무엇을 하는지 이해해야한다. AnnotationConfigApplicationContext은 스프링 컨테이너를 생성하는 역할을 하고 있다. 그리고 생성 후에 bean을 관리하고 의존성을 주입하게 된다. static class TestBean은 스프링 컨테이너에 의해 관리되는 빈이 된다. 만일 따로 선언하지 않고 static class TestBean에 선언하게 되면 주기가 꼬일 수 있게된다. 스프링에 의해 관리되어야할 빈이 그 안에서 스프링을 관리할 수 있도록 선언하고 있으니 주기가 꼬여 제대로 실행되지 못할 수 있다.

 

 

 

 

---

 

 

 

 

Q.  롬복(LomBok) 이란?

A. 코드 반복 작성을 줄여주는 코드 다이어트 라이브러리

 

 

 

✔️  OrderServiceImpl (LomBok)

 

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

 

 

 @RequiredArgsConstructor

: 초기화 되지않은 final 필드나, @NonNull이 붙은 필드에 대해 생성자를 생성하며, @Autowired를 사용하지 않고 의존성 주입한다.

 

 

 

 

- @RequiredArgsConstructor 출처

@RequiredArgsConstructor란?

 

 

 

- 롬복 사용 예시 출처

[java] 롬복 lombok 이란?

 

 

 

---

 

 

 

 

✔️  Autowired 필드 명 매치

 

<기존 코드>

@Autowired
 private DiscountPolicy discountPolicy

 

 

필드가 두 개 (rateDiscountPolicy, fixDiscountPolicy)가 존재한다며 오류가 발생했다.

 

 

<변경 후 코드>

 @Autowired
 private DiscountPolicy rateDiscountPolicy

 

 

@Autowired는 DiscountPolicy를 타입의 빈을 주입하기 위해 DiscountPolicy를 찾아나서게 된다. 그런데 DiscountPolicy 타입에는 rateDiscounPolicy와 fixDiscountPolicy인 동일 타입의 빈이 두 개가 있음을 알게된다. 그렇기에 오류가 발생하고 코드를 변경하여 타입 기반에서 이름 기반 코드로 수정시켜준 것이다. rateDiscountPolicy 빈이 제대로 등록되어있다면 해당 빈으로 주입한다.

 

 

 

 

---

 

 

 

✔️  @Qualifier 사용

 

 

►  빈 등록시 @Qualifier  추가 구분자 적어주기

 

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

 

 

Q. 같은 타입의 다른 빈에도 @Qualifier을 꼭 사용해야하는가?

A. 사용하지 않는다고 해서 꼭 문제가 생기는 것이 아니라서 무조건 붙여야하는 것도 아니다. 하지만 만약 같은 타입의 빈이 2개 이상인 경우 구분자를 붙이지 않은 다른 빈을 가져오고자 할 때  구분자를 붙이지 않은 또 다른 빈과 오류가 발생할 수 있다. 그렇기에 다른 빈에도 @Qualifier을 사용하여 정확하게 구분지어주는 것이 좋아보인다. 

 

 

 

 

►  생성자 자동 주입

public OrderServiceImpl(MemberRepository memberRepository
		,@Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {

 

여기서 @Qulifier을 붙여주면 서로 같은 @Qulifier을 찾으러 다닌다. 만일 붙이지 않았다고 해도 mainDiscountPolicy인 스프링 빈을 찾으러 다닐 것이다. 

 

 

 

 

---

 

 

 

✔️  @Primary 사용

 @Component
 @Primary
 public class RateDiscountPolicy implements DiscountPolicy {}

 

@Primary를 붙여서 DiscountPolicy의 타입에서 RateDiscountPolicy 빈이 가장 우선적으로 의존성 주입되도록 하는 방식이다. 메인 데이터베이스의 커넥션 획득이 필요한 경우 @Primary를 사용하고 서브 데이터베이스 커넥션 획득이 필요한 경우 @Qualify를 사용하는 것이 용이하다.

 

 

 

 

---

 

 

 

✔️  MainDiscountPolicy

애노테이션 직접 만들기

 

 

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

 

@Target

: 애노테이션 적용 대상

 

 

@Retention

: 애노테이션 지속 시간 결정

 

 

@Documented

: 애노테이션 정보를 javadoc으로 작성한 문서에 포함

 

 

@Qualifier("mainDiscountPolicy")` 이렇게 문자를 적으면 컴파일시 타입 체크가 안되기 때문에 애노테이션을 직접 만들주었다. 

 

 

 

- 애노테이션 출처

[Java] 자바 메타 어노테이션 정리 및 활용

 

 

 

@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy { } 

 

이렇게 사용이 가능해진다. 생성자 주입이나 수정자 주입에도 마찬가지로 사용가능하다.

 

 

 

 

 

---

 

 

 

✔️  AllBeanTest

해당 타입의 모든 빈이 필요한 경우 Map과 List를 사용한다.

 

 

►  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");

 

AutoAppConfig와 DiscountService 클래스를 기반으로 스프링 컨테이너 ac를 만들었다. 그리고 DiscountService 객체를 찾아  DiscountService 타입의 discountService 이름으로 해당 빈을 반환한다. member는 10000을 주문했고, Vip 등급으로 fixDiscountPolicy를 써서 discount를 진행한다.

 

 

 

- getBean 출처

[Spring] getBean() 메서드의 역할과 활용 방법

 

 

 

 

►  DiscountService

public DiscountService(Map<String, DiscountPolicy> policyMap,List<DiscountPolicy> policies){
            this.policyMap = policyMap;
            this.policies = policies;
}

 

생성자를 만들었다. 생성자는 DiscountPolicy 타입을 <빈이름, 빈> 쌍으로 받는 Map이 있고, 모든 DiscountPolicy 빈을 리스트 형태로 받는 List로 만들었다. 

 

 

 

 

••• 이어서 다른 코드 부분 •••

 

 

 

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

 

이 메서드가 할인 정책을 적용하게 한다. discountCode는 Test 코드에서 fixDiscountPolicy로 받았다. 그러면 policyMap을 통해 fixDiscountPolicy 빈을 찾아 discountPolicy라는 이름으로 받는다. 그러면 discountPolicy는 fixDiscountPolicy가 되는거고 fixDiscountPolicy의 정책인 'Vip는 얼마를 구매하든 1000원을 할인해주는 것'에 맞춰 할인이 진행된다. 그렇다면 member는 vip이며 10000원을 구매했다는 test 코드에 맞춰 1000원을 할인해주면 되는 것이다.

Map과 List를 사용하여 타입에 맞는 모든 빈을 가져온 후, 고객 혹은 테스트에 맞는 빈을 찾아 메서드를 수행하는 방식이다.

 

 

 

Q. 모든 빈을 가져올 때 꼭 Map과 List 둘 다 써야하는걸까?

A. 하나만 사용한다고 해서 어떤 문제가 생기는 것은 아니다. Map은 <키 혹은 이름>을 가지고 빈을 빠르게 찾는 것이고, List는 순서에 따라 모든 빈을 처리할 수 있는 특성을 가지고 있다. 현재는 적은 빈으로 테스트를 진행하고 있지만 실무는 훨씬 많은 빈으로 테스트 혹은 프로그램을 돌리기 때문에 두 특성을 모두 가지고 있어야 유연하게 적용할 수 있다.