[ DI 의존관계 ] 생성자 주입, 필드 주입

DI 의존관계 주입 3가지

의존관계 주입에는 3가지가 있지만 2가지인 생성자 주입과 필드주입에 대해 알아보겠다.

• 생성자 주입
• 필드 주입
• 세터 주입

생성자 주입

//AppConfig.java 
@Bean
public MemberService memberService() {
	return new MemberServiceImpl(memberRepository());
}

//MemberServiceImpl
private final MemberRepository memberRepository;

public MemberServiceImpl(MemberRepository memberRepository) {
	this.memberRepository = memberRepository; 
}

1. AppConfig 파일에서 memberSerivce()메서드를 호출하면서 결과값으로 MemberServiceImpl() 생성자를 호출한다.
2. memberRepository 메서드를 호출하여 MemberRepository 객체를 MemberServiceImpl의 생성자에 전달하여 의존성을 주입한다.

생성자 주입의 장점

• 불변성: 생성자 주입은 클래스의 인스턴스를 생성하는 시점에 의존성이 설정되므로 이후에 의존성을 변경하려면 새로운 인스턴스를 생성해야하므로 변경이 어렵다.
• 테스트 용이성: 생성자 주입은 TDD시에 생성자 주입을 통해 테스트가 가능하다. (필드주입은 안됨)
  테스트 시 Mock(가짜) 객체를 사용하는데, 이때 생성자를 통해 전달이 가능하다.
• 명시적인 의존성: 클래스가 어떤 의존성을 필요료 하는지 명확하게 보여준다. 넣지않을 경우에는 컴파일오류가 발생한 것을 확인할 수 있다.

필드 주입

//AppConfig.java
@Bean 
public MemberService memberService() {
	return new MemberServiceImpl();
}

//MemberServiceImpl.java 
@Autowired
MemberRepository memberRepository

1. AppConfig 파일에서 memberService()를 호출하면 return 값으로 MemberServiceImpl()을 호출하여 MemberServiceImpl 인스턴스를 생성한다. @Bean 어노테이션을 통해 메서드를 빈으로 등록하고 있다. (@Bean은 따로 정리하겠음)
2. MemberServiceImpl 에서는 @Autowired를 통해 memberRository를 필드주입을 해준다.

필드 주입의 장점

• 편리성: @Bean, @Autowired 어노테이션을 통해 말 그대로 필드에 주입함으로써 의존관계 설정완료

필드 주입 단점
(this.memberRepository가 NPE 오류발생)

• TDD 테스트 제약: 필드 주입은 객체 인스턴스를 생성할 때, 해당 필드에 의존성을 주입한다.
  테스트코드에서는 Mock 가짜객체를 대체하여 사용하는데 필드주입은 해당 필드에 의존성이 주입된된다. 스프링 컨테이너가 없으므로 자동으로 의존관계가 이루어지지 않는다.

생성자 주입과 비교
1. 생성자 주입의 명확성

• 의존관계를 찾아보면 생성자 주입 사용을 추천한다. 그 이유는 생성자 주입은 의존성을 생성자의 매개변수로 명시적으로 전달하는 방식이여서, 누락되거나 할때 컴파일오류가 발생하여 고치기가 쉽다. 반면에 필드주입은 필드에 직접 명시함으로써 생성자 주입처럼 명확하게 의존성을 매개변수로 표현하지 않는다. 자동으로 의존성을 주입하기 때문에 편리하지만, 의존성에 있어 명확하지 않다.