.시작하기전에
Spring Boot로 sns 서버 프로젝트를 진행하며 인증시스템을 도입하기위해 Spring Security에 세샨대신 Jwt를 사용하여 인증 로직을 짜고 있었다.
대부분의 개발선배님들의 코드에서 RequiredArgsConstructor어노테이션이 달려있었고 의존성주입에 관해서 의문점이 생겼다.
나는 기존에 Repository나 Service등을 Autowired를 사용하여 의존성을 주입했다.
참 게이른 생각이었지만 Autowired만 쓰면되는데 굳이 생성자를 통한 의존성 주입을 공부해야할 필요성을 못느꼈다.
그래서 오늘은 Autowired와 RequiredArgsConstructor의 차이점을 알아보고자 한다.
.Autowired 특징
Autowired는 필드주입방식의 의존성 관리 방법이다.
필드주입의 유일한 장점으로는 간편하게 의존성을 주입할수있는것이다.
아래 코드로 Autowired 주입방식을 확인해보자
public class UserService {
@Autowired
private UserRepository userRepository;
}위 코드로 볼수있듯이 Autowired를 통한 의존성 주입은 매우 간단하다.
하지만 편안함의 대가로 많은 단점을 가지고 있는데 단점은 다음과 같다.
-
단일책임의 원칙 위반 가능성
의존성 주입이 간편하고 코드가 짧은 만큼 그 위기감을 느끼기 어렵다.
생성자를 직접 사용할 경우에는 생성자의 파라미터가 쌓이며 클래스 하나가 과한 업무량을 가질지 모른다는 위기감을 꺠우치게 해준다.
생성자를 어노테이션으로 대체한다면 사실 이점에서는 큰 차이가 없긴하다. -
코드 변이의 가능성
이후 설명할 RequiredArgsConstructor을 통한 생성자 주입방식을 활용할 경우에는 final옵션을 사용할 수 있기때문에 객체가 변질될 가능성이 배제된다.
하지만 Autowired를 통한 필드주입방식은 final옵션을 사용할 수 없기때문에 코드가 변질될 가능성이 존재한다.
이는 로직에 따라 큰 에러가 발생할 가능성이 있기에 중요한 문제이다. -
불확실한 참조
Autowired는 DI가 타입이 같은 빈이 발견되면 그냥 주입해준다.
지금까지 주입이 간편하다고 말한 이유인데 이것이 문제가 되는 이유는 같은 타입의 다른 객체가 여러개일때 문제가 발생한다.
DI가 타입만 보고 내려주기때문에 서로다른 A타입의 객체가 두개 존재한다면 Autowired는 에러를 띄울 수 밖에 없다. -
순환참조의 가능성
생성자를 통한 의존성 주입은 클래스가 순환참조가 의심되면 런타임이 Exception을 발생시키기때문에 미리 코드의 문제점을 파악할 수 있다.
DI, IoC, Bean에 대한 이해도가 높다면 이보다 더 많은 단점이 보일 수 있겠지만 나도 공부중인 관계로 여기까지만 이해했다.
이러한 문제점때문에 Autowired는 스프링 및 intellij에서도 지양하고 있다.
.RequiredArgsConstructor 특징
사실 Autowired의 단점을 뒤집으면 생성자의 장점이 되긴한다.
추가적으로 다시한번 설명해보고자한다.
-
코드 변이에 대한 안전성
일단 RequiredArgsConstructor은 생성자 중에서도 final이 붙은 주입에만 생성자를 만들어준다.
final이 붙어있기때문에 인스턴스가 생성될때 1번만 참조되므로 코드 변이의 걱정은 사라진다. -
순환참조에 대한 안전성
생성자 어노테이션을 사용할 경우에 순환참조가 일어날시 Exception이 발생하여 컴파일중에 에러가 발생한다.
이를 통해 테스트 단계에서 순환참조를 파악하여 수정할 수 있다.
음.. 더 다양한 장점은 있겠지만 내가 이해한 각각의 장단점은 이렇다.
개인적으로 RequiredArgsConstructor의 장점보다 Autowired의 단점이 더욱 와닿는다.
어째서 Autowired를 지양하고자 하는지 이해했으며 내 프로젝트에도 적용을 했다.
의존성 주입단계에서 신경써야하는 것이 무엇인지 순환참조, 코드변이, 자바의 5원칙 등 다양한 것을 깨달으며 얻어가는 것이 많은 포스팅이었다.
