IOC(Inversion Of Control), 제어의 역전
- 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것
1) 전통적인 방식
- 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행함.
- 즉, 클라이언트 구현 객체가 프로그램의 제어 흐름을 스스로 조정.
전통적인 방식은 DIP, OCP, SRP 위반
2) IOC 기반 방식
- 구현 객체는 자신의 로직을 실행하는 역할만 담당.
- 프로그램의 제어 흐름은 클라이언트가 구현 객체가 아닌 스프링(컨테이너)가 가져감.
- 프로그램에 대한 제어 흐름에 대한 권한은 모두 컨테이너가 가져감.
IOC 기반 방식은 DIP, OCP, SRP 준수
그렇다면
"제어 흐름이 스프링에게 넘어갔다고 했는데, 실제로 어떻게 그런 일이 가능한가?"
"구현 객체를 직접 생성하지 않는다면, 클라이언트는 어떻게 필요한 의존 객체를 사용할 수 있는가?"
"클라이언트 코드를 변경하지 않고도 구현 객체를 바꿀 수 있다는 건 도대체 무슨 의미일까?"
→ 이때 등장하는 것이 바로 DI, 즉 의존 관계 주입이라는 개념
'[Spring]' 카테고리의 다른 글
[Spring] Restful API 설계 원칙 (0) | 2025.03.15 |
---|---|
[Spring] DTO, VO, Entity (0) | 2025.02.18 |
[Spring] DI (0) | 2025.02.13 |
[Spring] 스프링이란? (0) | 2025.02.01 |
댓글