스프링 프레임워크의 주요 철학 중 하나로 가장 큰 테두리 중 하나는 DI(Dependency Injection) 이다.
Dependency Injection 에 대해 먼저 살펴보자면, 말그대로 "의존성 주입" 을 말하며, 스프링 프레임워크는 Framework 레벨에서 DI 를 제공해준다.
Spring 의 Container 들은 Bean 객체들을 관리하는 데 있어서 DI 를 이용하며 이를 통해 Life Cycle 을 용이하게 관리할 수 있으며 이 것이 스프링 프레임워크의 핵심적인 동작이라고 할 수 있다.
즉, 프레임워크 레벨의 관리를 통해 개발자는 객체들간의 의존성에 신경을 덜 쓰고 Coupling 을 줄일 수 있으며 높은 재사용성과 가독성있는 코드를 만들어낼 수 있다.
이를 제어의 역전(Inversion Of Control) 이라 하며, 이것이 스프링 프레임워크의 특징적인 개념인 IOC 이다.
(클래스 관리의 주체가 개발자가 아닌 프레임워크라는 뜻이다.)
그리고 결과적으로 이러한 개발 편리성은 높은 생산성을 이끌어낼 수 있는 스프링의 큰 장점이다.
- Dependency Injection 을 통해 얻을 수 있는 장점 -
(1) Dependency Reduction : 객체 상호 간 의존성 관계를 줄여준다.
(2) Reusable Structure : 코드의 재사용과 조합이 용이하다.
(3) Readability : 코드들이 분리되다보니 가독성이 뛰어나진다.
(4) Loose Coupling & Easy to change : 구조는 변화에 민감하지 않을 수 있다.
그 외에 테스트가 용이하고 다양한 패턴을 적용하는 데 유연하다는 점도 큰 장점이 될 수 있다.
Spring Framework 에서 개발자가 Dependency Injection 을 하는 데 몇가지 방법들이 있다.
(1) Field Injection
가장 흔히 볼 수 있는 Injection 방법으로 사용하기도 간편하고 코드도 읽기 쉽다.
public class Sample {
@Autowired
private Example example;
}
많이 사용됨에도 불구하고 Field Injection 을 통한 의존성 주입은 권장되지 않는다.
이유는 너무 추상적인 Injection 기법 때문이다. 의존성 주입이 쉽기 때문에 Dependency 관계가 복잡해질 우려가 있으며 이는 Framework 의 사용에 있어 다음과 같은 안티패턴적 측면을 갖는다.
- Single Responsibility Principle Violation
: 너무나 쉬운 의존성의 주입은 하나의 클래스가 지나치게 많은 기능을 하게됨으로써 초기 설계의 목적성이자 "객체는 그에 맞는 동작만을 한다." 는 원칙에 위배되기 쉽다.
위배된 경우 리팩토링의 비용은 크다.
- Dependency Hiding
: 추상화된 의존관계는 의존성을 검증하기 힘들게 만든다.
- DI Container Coupling
: Field Injection 을 사용하면 해당 클래스를 곧바로 Instant 화시킬 수 없다. 이 부분 때문에 Constructor Injection 이 권장되는 이유이기도 하다.
가령 Container 밖의 환경에서 해당 클래스의 객체를 참조할 때, Dependency 를 정의해두는 Reflection 을 사용하는 방법 외에는 참조할 수 있는 방법이 없다.
DI Framework 는 Field Injection 된 클래스의 Instance 화에 대해서 Null Pointer Exception 을 만들어낼 것이다.
- Immutability
: Field Injection 된 객체는 final 을 선언할 수 없으므로 가변적(Mutable)이다. 객체는 변경될 수 있으며 이에 대한 대응에는 큰 비용이 든다.
(2) Setter Injection
선택적인 의존성을 주입할 경우 유용하며, Spring 3.x 대까지 가장 권장되던 방식이다.
public class Sample {
private Example example;
@Autowired
public void setExample(Example example) {
this.example = example;
}
}
Field Injection 으로 인한 패턴적 위험성을 상당 부분 해소한다. Optional Injection 의 경우 권장되는 방식이다.
@Required 어노테이션을 이용하면 의존성이 필요한 Setter 를 만들 수 있다.
(3) Constructor Injection
Spring 4.x 이상부터 권장되는 방식이다.
public class Sample {
private final Example example;
@Autowired
public Sample(Example example) {
this.example = example;
}
}
코드를 통해 알 수 있듯, final 선언이 가능하며 Immutability 에 대한 해소가 가능하며 의존성의 순환 참조(Circular Dependency) 에 대한 예방이 가능하다.
순환 참조 시 위의 방법을 이용한 코드는 BeanCurrentlyCreationExeption 을 발생시킨다.
역시 위에서 언급된 Container Coupling 문제도 해결이 되는데, 생성자를 통한 Injection 이므로 즉각적인 Instance 화 등에 대한 문제도 해결된다.
많은 예제 코드들이 Field Injection 방식을 사용하고 있으나 Constructor Injection 의 사용이 권장된다.
추가로 참조한 바에 의하면 Spring Team 에서는 Setter 방식을 좀 더 권장하며 이유는 생성자가 지나치게 복잡해질 수 있기 때문이라고 한다.
패턴적 관점에서 이견이 있는 듯 하다.
Spring 4.3 이상부터는 생성자가 하나인 경우 @Autowired 를 사용하지 않아도 무방하다.
정리에 있어 다음 링크들을 참조하였다.
https://www.vojtechruzicka.com/field-dependency-injection-considered-harmful/
https://dzone.com/articles/dependency-injection-pitfalls
https://blog.outsider.ne.kr/753
