Constructor Injection 방식을 권장하는 이유

이전 포스팅에서 autowired 방식과 requiredArgConstructor를 사용하여 final로 변수 선언하여 의존성 주입하는 방법에 대해서 다룬 글이 있다.

자세한 내용은 아래 참고 포스팅을 확인하길 바란다.

이 포스팅에서는 좀더 심화되게 Constructor Injection 방식을 권장하는 이유에 대해서 다뤄보려고 한다.

 

일단 스프링부트에서는 Constructor Injection 방식이 단일 생성자이면서 , 그 생성자의 파라미터가 빈 일경우 스프링이 자동으로 주입을 해준다고 하고, 그럼으로써 @Autowired를 사용하지 않아도 되게 된다.

 

일단 의존성 주입의 방법은 3가지가 있다.

• 생성자 주입(Constructor Injection)
• 필드 주입(Field Injection)
• 세터 주입(Setter Injection)

여기서 생성자 주입이 권장하는 방식인데 자세한 코드는 아래 참고 포스팅에서 확인하길 바란다.

 

생성자 방식을 권장하는 이유는 다음과 같다.

 

1. 단일 책임의 원칙(SRP)

- 생성자의 인자가 많아지면 하나의 클래스가 여러곳에서 많은 책임을 맡게 된다.

그럴경우 Constructor Injection 을 사용해서 의존관계, 복잡성을 쉽게 알수가 있다.

 

2. 의존성을 숨길수 있다.

DI(Dependency Injection) 컨테이너를 사용한다는 것은 클래스가 자신의 의존성만 책임지는게 아니고 제공된 의존성 또한 책임진다.

그래서 클래스가 어떤 의존성을 책임지지 않을 때, 메소드나 생성자를 통해 커뮤니케이션이 되어야한다. 하지만 Field Injection은 숨은 의존성만 제공해준다.

 

3. DI 컨테이너의 결합성과 테스트의 용이성

DI 프레임워크의 핵심은 관리되는 클래스가 DI 컨테이너에 의존성이 없어야한다.

필요한 의존성을 전달하면 독립적으로 인스턴스화 할수 있는 POJO 여야한다.

 

4. Immutability

불변 객체여야하고 그래서 final로 선언을 해야 가능한방식인데

필드 주입방식은 final로 선언이 불가능해서 중간에 변경 위험이 있다.

 

5. 순환 의존성

가장 중요한 이유이기도 한 이 순환의존성은 생성자 주입 방식에서 순환 의존성을 가질경우 BeanCurrentlyCreationException 을 발생시킴으로써 순환 의존성을 알수 있다.

A 클래스가 B 클래스를 참조하는데, 다시 B 클래스가 A 클래스를 참조하는 경우 순환 의존성이 된다.

 

이런 이유때문에 Constructor Injection 방식이 지향된다.

---

참고 포스팅

https://thenicesj.tistory.com/278

@Autowired 대신 @RequiredArgsConstructor