[기술면접스터디] DI 필드 vs 생성자 주입 방식

 🏷 DI : 

외부에서 두 객체간의 관계를 결정해주는 디자인패턴

강하게 결합된 클래스들을 분리하고, 애플리케이션 실행 시점에 객체간의 관계를 결정해줌으로써 

결합도를 낮추고 유연성을 확보해주는 역할을 함

---

📘 결합도가 높은건 무엇일까?

결합도는 다른 모듈과의 의존성을 뜻함 모듈 수정을 위해 다른 모듈의 변경을 요구하는 정도 

( 모듈이 다른 모듈에 의존하는 정도의 척도 or 모듈과 모듈간의 상호 결합 정도를 나타냄 )

 

• 강한 결합 : 
  - 객체 내부에서 다른 객체를 생성하는 것은 강한 결합도를 가지는 구조 
  - A 클래스 내부에서 B라는 객체를 직접 생성하고 있다면, B 객체를 C 객체로 바꾸고 싶은 경우에 A클래스도 수정해야하는
    방식

 

• 느슨한 결합 
  - 외부에서 생성된 객체를 인터페이스를 통해 객체를 주입받는 구조 
  - 결합도를 낮출 수 있고, 런타임시 의존관계가 결정되기 때문에 유연한 구조를 가진다.

---

📗 DI의 세가지 주입 방식

1. 생성자 주입

@Controller 
public class Controller{
   private final Service service;

   @Autowired 
   public Controller(Service service){
     this.service = service; 
   }
}

# 생성자에 @Autowired를 붙여 의존성을 주입받는 방법.

   2. 필드 주입

@Controller
public class Controller{
  @Autowired 
  private Service service;
}

# 필드에 @Autowired를 붙여 의존성을 주입받는 방법.
# 생성자 주입과 다르게 필드를 final로 정의할 수 없음.
# 주입이 동시에 일어나 겹치는 경우 순환참조 에러가 발생함.

   3. 수정자(Setter) 주입

@Controller 
public class Controller{
   private Service service;

   @Autowired 
   public setService(Service service){
     this.service = service; 
   }
}

# 사용자 정의 메서드를 통해 의존관계를 주입
# 객체가 변경될 필요성이 있을 때만 사용
# final 키워드 선언 불가
# 함수이름이 setXX일 필요는 없지만, 일관성을 위해 사용하는게 좋음

---

📒 3가지 방식 중 어떤 방식을 사용하는게 좋을까?

: 여러 방식 중 생성자 주입 방식이 가장 권장되는데 왜일까❓

---

1) 순환 참조로 인한 오류 감지 가능

: 서로 다른 빈들이 서로 참조를 맞물리게 주입되면서 생기는 현상

ex ) Bean A -> Bean B 참조 / Bean B -> Bean A를 참조해야하는 경우 순환참조 문제가 발생하게 됨

 

👉 스프링에서 어떤 스프링 빈을 먼저 만들어야 할 지 결정할 수 없게 된 상황

 

1-1 ) 생성자 주입 방식의 순환 참조 문제

@Component
public class BeanA {
	private BeanB beanB;

	public void BeanA(BeanB beanB){
		this.beanB = beanB;
	}
}

@Component
public class BeanB {
	private BeanA beanA;

	public void BeanB(BeanA beanA){
		this.beanA = beanA;
	}
}

애플리케이션 구동 시 IOC는 Bean A를 생성하기 위해 Bean B를 주입해줘야하기 때문에 Bean B를 찾고,

Bean B를 생성하려하니 Bean A가 필요하여 Bean A를 찾으면서 무한 반복이 생기게 되어 실행 시 오류가 발생하게 됨

 

1-2 ) 필드, Setter 주입 방식의 순환 참조 문제

@Component
public class BeanA {
	@Autowired						// 필드 주입 방식
	private BeanB beanB;				

	public void run(){
		beanB.run();
	}

	public void call(){
		log.info("called BeanA");
	}
}

@Component
public class BeanB {
	@Autowired						// 필드 주입 방식
	private BeanA beanA;

	public void run(){
		log.info("Called BeanB");
		beanA.call();
	}
}

@Component
public class BeanA {
	private BeanB beanB;

	@Autowired
	public void setBeanB(BeanB beanB){
		this.beanB = beanB;
	}

	public void run(){
		beanB.run();
	}

	public void call(){
		log.info("called BeanA");
	}
}

@Component
public class BeanB {
	private BeanA beanA;

	@Autowired
	public void setBeanA(BeanA beanA){
		this.beanA = beanA;
	}

	public void run(){
		log.info("Called BeanB");
		beanA.call();
	}
}

 

두 방식은 생성자 주입 방식과 다르게 애플리케이션 구동 당시에는 필요한 의존성이 없을때는 Null 상태로 유지하고,

실제로 사용하는 시점에 주입을 하기 때문에 애플리케이션 구동 당시에는 순환참조문제가 발생하지 않음.

순환참조를 일으킬 수 있는 메서드를 호출하는 시점에 발생한다.

 

👉 생성자 주입은 생성자에서 의존관계 주입이 일어나기 때문에 생성자가 실행 될 때 의존 객체의 Null 여부를 검사하므로 
      컴파일시에 오류를 발생시켜 런타임시에 오류가 발생하는 큰 문제를 미연에 방지할 수 있음..!! 
      ( 필드, Setter 주입은 실제로 사용하는 시점에 문제가 발생하므로 런타임시에 오류가 발생 )

 

1-2 ) 의존성 주입이 필요한 필드를 Final로 선언 가능

 

- 필드/Setter 방식을 사용하게 되면 Final로 선언이 불가하여 객체의 불변성(Immutable)을 확보할 수 없다.

 

 

1-3 ) 테스트코드 작성 용이

 

- 필드 주입을 사용하여 작성된 클래스라면, 단위 테스트시 의존 관계를 가지는 객체를 생성하여 주입할 수 없음.
   ( 스프링 IOC가 생성해서 주입해주는 방식이고, 외부에 노출되어있는것이 하나도 없기 때문에 의존관계를 가지고 있는 메서드의 단위테스트를 작성하면
      NullPointException이 발생함)

 

 

✨ ) 생성자 주입 Code를 줄일 수 있는 유용한 어노테이션들 

@NoArgsConstructor - 기본 생성자 생성
@AllArgsConstructor - 모든 필드를 초기화하는 생성자 생성
@RequiredArgsConstructor - 초기화 되지 않은 모든 final 필드 & @NonNull 마크가 있는 필드를 초기화하는 생성자 생성