이전 글에서 언급되었던 OCP,DIP 의 문제점을 스프링에서 해결하는 방법 클라이언트 코드를 변경하지 않고, 새로운 구현체로 갈아끼우려면??
관심사의 분리#
어플리케이션의 전체 동작 방식을 구성(config) 하기 위해서, 구현 객체를 생성 하고, 연결 하는 책임을 가지는 별도의 생성 클래스
- 어플리케이션의 실제 동작에 필요한 구현 객체를 생성
- 생성한 객체 인스턴스의 참조(rference)를 생성자를 통해서 주입
- 즉, 생성자를 통해 어떤 구현체가 들어올지는 오직 외부에서 결정됨 => 의존관계에 대한 고민은 외부에 맡기고, 실행에만 집중 클라이언트 코드는 절대 변경되지 않음
IOD, DI, 컨테이너#
IOC (제어의 역전)#
Inversion of Control
- 프로그램의 제어 흐름을 직접 제어하지 않고, 외부에서 관리(프레임워크)
DI (의존관계 주입)#
Dependency Injection
정적인 클래스 의존관계
- 어플리케이션을 실행하지 않아도
import만으로 분석이 가능
**동적 객체 의존관계 ** DI
- 어플리케이션 실행 시점에 생성된 객체 인스턴스의 참조가 연결
- 클라이언트 코드를 변경없이 클라이언트 호출 대상의 타입 인스턴스 변경
IOC컨테이너 == DI컨테이너#
- 객체를 생성,관리,의존관계 연결해주는것