(+) 생성자 주입 장점
Last updated
Last updated
전반적으로 이 이슈에 대해서 작성자분이 정리를 깔끔하게 잘 해놓으셨다. 내가 이해할 포인트는 DI는 반드시 '생성자 주입'으로 해야한다는 것과 왜 그래야 하는지 이다.
의존성 주입 방식은 여러 가지 방식이 존재한다. 생성자 주입 말고도 @Autowired 라는 어노테이션을 이용하는 방식이 대표적이다. 사용해본 적은 없지만 setter 주입 방식도 있다고 한다.
생성자 주입(Constructor Injection): 의존성을 클래스의 생성자를 통해 주입하는 방식입니다. 의존성을 필수적으로 주입받아야 하는 경우에 주로 사용됩니다. 생성자를 통해 의존성을 주입받으면, 해당 객체는 의존성을 가진 상태에서 생성되므로 일관성과 안정성을 보장할 수 있습니다.
Setter 주입(Setter Injection): 의존성을 클래스의 Setter 메서드를 통해 주입하는 방식입니다. Setter 메서드를 통해 의존성을 동적으로 주입할 수 있습니다. Setter 주입은 선택적으로 의존성을 주입받아야 하는 경우에 유용합니다.
필드 주입(Field Injection): 의존성을 클래스의 필드에 직접 주입하는 방식입니다. 주로
@Autowired나@Inject와 같은 어노테이션을 사용하여 필드에 의존성을 주입합니다. 필드 주입은 코드의 간결성을 위해 사용될 수 있지만, 테스트 용이성이나 의존성 누락을 파악하기 어려운 단점이 있습니다.
생성자 주입을 사용하면 A 객체가 B 객체를 의존하고, B 객체는 A 객체를 의존하는 순환 의존성을 방지할 수 있다. 애초에 컴파일 타임에 에러가 발생한다. 생성자 주입이 아니라 다른 방식으로 주입할 경우 런타임에 호출시 에러가 발생한다.
생성자 주입으로 객체를 생성할 경우 한번 생성되고 나서 필드(의존성)가 바뀌지 않기 때문에 불변이 유지된다. 불변이 유지된다는 것은 곧 일관성이 보장된다는 의미이다.
생성자 주입 방식을 사용할 경우 테스트 환경에서 mock 객체를 이용해서 객체를 만들 수 있으므로 테스트가 용이하다.
이 외에도 더 들 수는 있으나 이정도면 충분한 것 같다. 다른 항목들은 을 참고하자.