모각소-8(의존관계 주입)

오늘은 웹 백엔드 개발을 배우기 위해 김영한 강사님의 강의를 들었다.
사실 어제도 들었다.
사실 이번 방학 내내 들었다. 개강할때는 고수가 되어 나가자.

다양한 의존관계 주입 방법

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

생성자 주입

• 이름 그대로 생성자를 통해서 의존관계를 주입하는 것이다.

• 특징

  • 생성자 호출시점에 딱 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;
 }
}

중요! 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 된다. 물론 스프링 빈에만 해당한다

수정자 주입(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;
 }
}

자바 빈 프로퍼티 규약 예시

class Data {
 private int age;
 public void setAge(int age) {
 this.age = age;
 }
 public int getAge() {
 return age;
 }
}

필드 주입

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

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

참고: 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야한다. 스프링 빈이 아닌 Member 같은 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작하지 않는다.

옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있다.
그런데 @Autowired 만 사용하면 required 옵션의 기본값이 true 로 되어 있어서 자동 주입 대상이 없으면 오류가 발생한다

자동 주입 대상을 옵션으로 처리하는 방법은 다음과 같다.

• @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) {

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

생성자 주입을 선택해라

과거에는 수정자 주입, 필드 주입이지만, 최근에는 DI프레임워크 대부분이 생성자 주입을 권장한다.

불변

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

누락
프레임워크 없이 순수한 자바 코드를 단위 테스트하는 경우가 진짜 많다.

즉,
1. final을 통해서 생성자를 한번만 실행하게 만들어서 제어를 할 수 있다. -> 값이 설정되지 않는 오류를 컴파일 단계에서 막을 수 있다.
2. test에서 쉽게 의존관계를 주입할 수 있다.

정리

• 생성자 주입 방식을 선택하는 이유는 여러가지가 있지만, 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법이기도 하다.
• 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자주입과 수정자 주입을 동시에 사용할 수 있다.
• 항상 생성자 주입을 선택해라! 그리고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 않는게 좋다

롬북과 최신 트랜드

막상 개발을 해보면, 대부분이 다 불변이고, 그래서 다음과 같이 생성자에 final 키워드를 사용하게 된다.
그런데 생성자도 만들고, 주입받는 값을 대입하는 코드를 만들어야한다.

필드 주입처럼 쉽게 하는 방법은 없을까?

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

• 롬북이 생성자를 자동으로 생성해준다.

정리
최근에는 생성자를 1개 두고, @Autowired 를 생략하는 방법을 주로 사용한다.여기에 Lombok 라이브러리의 @RequiredArgsConstructor 함께 사용하면 기능은 다 제공하면서, 코드는 깔끔하게 사용할 수 있다.

조회할 빈이 2개 이상 - 문제

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

@Autowired
private DiscountPolicy discountPolicy

타입으로 조회하기 때문에, 다음 코드와 유사하게 동작한다.

ac.getBean(DiscountPolicy.class)

하지만, DiscountPolicy를 구현하는 두 구현체를 모두 component에 선언하게 되면 어떻게 될까?

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

위 처럼 코드를 설정하고 자동 의존관계를 주입해보면

@Autowired
private DiscountPolicy discountPolicy

NoUniqueBeanDefinitionException: No qualifying bean of type
'hello.core.discount.DiscountPolicy' available: expected single matching bean
but found 2: fixDiscountPolicy,rateDiscountPolicy

위와 같은 NoUniqueBeanDefinitionException이 나온다. 즉 같은 타입으로 넣을 수 있는 구현체가 2개가 존재한다는 사실을 친절하게 알려준다.

이 구현체 2개를 구별하여 자동적으로 선택하게끔 하는 방법은 다음에 알아보도록 하자.

모각소 소감

개발은 알아갈 수록 재밌지만, 알아갈 수록 앞으로 해야할 것이 보이기 때문에 포기하고 싶어지는 같습니다. 또한, 제가 어렵다고 느끼는 것을 유튜브에서 이미 쉽게해버리고 있는 다른 백엔드 개발자들을 볼때가 가장 힘든 것 같습니다. 하지만 모두가 처음에는 다 이랬을 것이라는 자기위로를 하며 오늘도 모각소를 통해서 한 발자국 더 나아갔습니다.
내가 배운 어려운 것을 쉽게 사용할때까지 열심히하기

---

출처 - 김영한 강사님의 스프링 기본편
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8