backend-framework/Spring

스프링 DI/IoC - 파트2(DI/IoC의 중요성)

여늘(yeonuel) 2024. 8. 5. 00:34

앞선 글에서는 난 “스프링 DI/IoC 핵심 내용을 요약 정리 글”을 작성했다. (스프링 DI/IoC - 파트1(핵심 내용 요약) - https://yeoneul-tech.tistory.com/m/132)

이제 하나 하나씩 깊게 파고들어보자. DI란 무엇일까?
“의존성 주입, 하나의 객체가 다른 객체의 의존성을 제공하는 것을 의미한다“

그러면 IoC는 무엇일까? ”제어의 역전, 결정권이나 제어권을 외부로 넘기는 것, 그래서 외부에서 결정하거나 제어할 수 있게 구성하는 것을 의미한다“

여기서 “의존성”의 의미는 ”특정 객체가 다른 객체를 알고있는, 사용하고 있는 것“을 의미한다. 즉, 해당 객체가
작동하려면 특정 객체를 사용해야하는 경우를 말한다.

그러면, 왜 DI로 의존성 객체를 주입 받아야 하는 것일까?
바로 관심사의 분리이다. 즉, 사용과 생성의 관점에서 코드를 분리하여 변경에 유리하도록 프로그래밍을 할 수 있게해야한다.

예를들어서, 밑에 코드를 보면 해당 객체가 내부에서 사용할 객체를 스스로 결정하고 생성한다. 또한, 생성된 객체를 사용해서 작동한다.

(코드)

여기에서의 문제점은 해당 객체가 SRP 원칙을 만족하지 못하고 있다는 것이다. 즉, 단일 책임 원칙을 만족하지 않고 ”생성“과 ”사용“이라는 책임을 동시에 지고 있다.

이럴경우, 해당 객체는 변경 포인트가 많아지게 되어 변경에 유리한 설계가 아니게 된다. 즉, OOP 프로그래밍을 하지 못하는 것이다.

이를 개선하기 위해서는 ”생성“과 ”사용“을 철저히 분리해야한다. 즉, 해당 객체는 ”사용“ 관점에만 집중하여 SRP 원칙을 충족해야한다.

또한, 이렇게 분리하게 되면 자바 소스 코드 뿐만아니라 설정 파일 등에서도 생성 정보를 제공하기 때문에 확장성이 매우 뛰어난 것을 확인 할 수 있다.

(코드)

스프링에서는 스프링 컨테이너가 빈을 등록, 관리, 자동주입, 의존관계 설정 … 을 처리해주고 사용자는 사용에 집중한 클래스를 작성하는 구성을 띄고 있다. 이를 그림으로 그리면 다음과 같다.

(칠판 그림)

이렇게 구성하면 좋은 점은 다음 그림을 통해 알 수 있다
- 1. 확장성이 매우 좋다
- 2. 유지 보수성이 뛰어나다
- 3. 테스트용 객체를 사용할 수 있다.

(칠판 그림)


따라서, 우리는 스프링의 첫 번째 핵심 기능인 DI/IoC 및 의존관계 설정에 대해서 배웠다. 이 기능을 통해 우리가 변경에 유리고 유연한 프로그래밍을 할 수 있도록 도와준다는 것을 알 수 있다.