IOC, DI
제어의 역전
스프링에만 해당하는 개념은 아닌듯 하고 모든 프레임워크에 해당하는 개념일 것이다.
모든 프레임워크는 프레임워크내에서 나의 코드가 돌아가기 때문 제어가 역전되었다.
(프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고, 대신실행해서 프레임워크를 기반으로 돌아간다면 프레임워크다.(Junit)
내가 작성한 코드가 직접 제어의 흐름을 담당하면 라이브러리 이다.)
제어의 역전은 프레임워크 같은게 호출을 대신 해주는것을 말함.
그런것들 제어권이 뒤바뀐다 해서 제어의 역전이라고 함.
(원래 객체 자체에서 필요한 의존객체를 new로 생성해서 사용하는데, 이런것들을 밖에서 해줌)
의존관계를 외부에서 주입시키면, 클라이언트의 코드를 변경하지 않아도 된다는 것이 큰 강점임.
특히, 이미 정적으로 의존관계를 맺어놓은 것이 있다고 해도, 이것들의 변경이 전혀 필요하지 않은게 장점이다.
쉽게 생각해서 그냥 정적인 의존관계가 모두 인터페이스 타입이고, 실객체를 생성자를 통해 외부에서 주입받으면 설계가 아주 잘된 코드라고 보면 된다.
(클라이언트 코드에서 import해놓은 정적 의존관계 클래스 들(서버)이 모두 인터페이스 타입일거고, 실 객체는 생성자를 통해 동적으로 외부에서 주입될테니 정적코드가 변경될 일이 없음)
IOC 컨테이너 Inversion of Control 제어의 역전
DI 컨테이너 Dependency Injection 의존관계 주입
IOC컨테이너는 쉽게말해서 객체의 생성을 담당하고,
DI컨테이너는 생성한 객체를 주입하는것을 담당
EX) 드라이버 클래스에서 실제 자동차 객체를 생성하는게 아니라, IOC컨테이너에서 만들고, DI 컨테이너가 주입한다.
실세계에서는 IOC컨테이너나 DI컨테이너를 비슷한 의미로 언급하는듯 함.( 또는 IOC컨테이너가 DI 를 해준다 라고 생각할수도 있을듯)
정확하게는 IOC컨테이너의 이름이 너무 범용적이라(JUNIT도 IOC가 된것임) 후대에 DI컨테이너라는 용어로 정착된듯 함.
DI가하는일이듯, 필요한 객체들을 조립해 준다고 하여 어셈블러 라기도 하며, 오브젝트를 만들어야 한다고 해서 오브젝트 팩토리 라고도 부름.
담당자 배정과 역할을 매우 명확하게 해야 한다.
예를들어 공연을 한다고치면 공연 주체자(main)이 모두 하는게 아니라,
- 배역(인터페이스, Interface)
- 배우(실구체. Impl)
- 기획자(배우를 실제 캐스팅하고 배역 관계에 따라 실제 배우를 설정하는 일, AppConfig)
등으로 일을 관심사를 분리하여 맡은 역할만 담당하게 구성을 해놓아야 한다. 이후에 공연 주체자가 모두 다 알고 있는 상태에서 지휘하는 것임.