🌱IoC,DI,컨테이너

제어의 역전 IoC(Inversion of Control)

구현 객체(작가 역할)이 프로그램의 제어 흐름 ( 배우 캐스팅 이라고 하던걸 ) 스스로 했다면, AppConfig 이후에는 구현 객체는 자기 로직만 실행하는 하는 역할을 하고(글의 전개만 신경쓰고) 프로그램의 제어의 흐름은 AppConfig 가 수행한다.

즉 누가 내 글에 케스팅될지는 모른체, 그냥 서사만 잘 쌓아올리면 되는게 제어의 역전(IoC)이다. ( 구현 객체가 누가 캐스팅 될 지 몰라서 제어의 역전이라고 하는 것 같다!) 

프레임워크 vs 라이브러리

- 프레임워크면 내가 작성한 코드를 제어하고, 대신 실행 ( JUnit)

- 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 라이브러리

의존관계의 주입 DI(Dependency Injection)

의존관계에는 정적인 클래스 의존 관계와 동적인 객체(인스턴스) 의 의존 관계가 있다.

정적인 클래스 의존 관계는

쉽게 말하자면 해당 클래스에서 import코드로 보이는 의존 관계이다. 
따라서 쉽게 분석가능하다. 

동적인 객체 의존 관계는 

애플리케이션이 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계이다. 즉 AppConfig에서 설정된 의존 관계이다. 

실행 지점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다. 쉽게 말하자면, 애플리케이션을 실행할 때, 캐스팅 된 배우를 클라이언트에게 넘겨주는 거다. 
이렇게 하면, 클라이언트의 코드는 변경하지 않고, 의존관계를 외부에서 쉽게 변경할 수 있다는 장점이 있다.! 

사실 앞에 적었던 이야기의 반복적인 이야기다. 결국은 캐스팅은 다른 곳에서 하고, 클라이언트는 글만 써라는 거다! 

IoC 컨테이너, DI 컨테이너 

App Config처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너, DI 컨테이너라고 한다. 

때로는 assembler, object factory 라고 하기도 한다.