IoC, DI, Container

1. 제어의 역전(Inversion of Control)

---

• 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행함
• 즉, 구현객체가 프로그램의 제어 흐름을 스스로 조종.
• 주우우욱 작성하다가 필요한거 있으면 호출해서 쓰고.. 자연스러움
• 근데 AppConfig이후 구현 객체는 온전히 자신의 로직을 실행하는 역할만 가짐.
• 프로그램의 제어 흐름에 대한 권한은 AppConfig가 가져감.
• 프로그램의 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라 함.

 

 

2. 프레임워크 vs 라이브러리

---

• 프레임워크가 내가 작성한 코드를 제어, 대신 실행함.
• 내가 제어의 흐름을 담당하면? 그건 라이브러리임.

 

 

3. 의존관계 주입(DI)

---

• 의존관계는 "정적인 클래스 의존 관계"와 "실행 시점에 결정되는 동적인 객체(인스턴스) 의존관계"를 분리해서 생각.
• 정적인 클래스 의존관계
  - 클래스가 사용하는 import 코드만 보고 의존관계 파단 가능. 애플리케이션을 실행하지 않아도 분석 가능.
  - 클래스 다이어그램
  

  

  
  - 참고로 intelliJ에서 다이어그램 볼 수 있다. 의존관계 확인 가능.
  

  

• 동적인 객체 인스턴스 의존 관계
  - 객체 다이어그램
  

  

  - 런타임에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서
    클라이언트와 서버의 실제 의존관꼐가 연결되는 것을 의존관계 주입.
  
  - 즉, 사용 영역 입장에서는 런타임에 구현객체가 뭐가 들어오는 지 알 수 있다. 이때 의존관계가 주입.
  
  - 객체 인스턴스를 생성하고, 그 참조값을 전달하여 연결됨.
  
  - 의존관계 주입을 사용하면 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경 가능
  
  - 의존관계 주입 사용하면 정적인 클래스 의존관계 변경하지 않고,
    동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있음.

 

 

4. IoC 컨테이너, DI 컨테이너

---

• IocC를 해주는 컨테이너, DI를 해주는 커네이너
• 우리가 만든 AppConfig처럼 객체를 생성하고 관리하고, 의존관계 연결해 주는 것을!
• IoC컨테이너, DI컨테이너라 부름. 보통  DI컨테이너라 부름.
• AppConfig의 책임 : 객체 생성 및 생성자를 통한 의존관계 주입, 프로그램 흐름 제어 권한.
• 애플리케이션 전체에 대하여 조립하니 어셈블러, 팩토리라고도 함