IoC, DI, 그리고 컨테이너

📍 SOLID 5원칙 중 3원칙

1. SRP 단일 책임 원칙

• 한 클래스는 하나의 책임만 가져야 한다.
• 구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당,
  클라이언트 객체는 실행하는 책임만 담당

2. DIP 의존 관계 역전 원칙

• 추상화에 의존해야하지 구체화에 의존하면 안된다.
• 의존성 주입은 이 원칙을 따르는 방법 중 하나
• 클라이언트 코드는 인터페이스만으로는 아무것도 실행할 수 없다.
  AppConfig가 객체 인스턴스를 클라이언트 코드 대신 생성해서
  클라이언트 코드에 의존관계를 주입했다.

3. OCP

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• AppConfig가 클라이언트 코드에 주입하므로 클라이언트 코드는 변경하지 않아도 됨

📍 IoC, DI, 그리고 컨테이너

제어의 역전 Ioc(Inversion of Control)

• AppConfig 등장 후 구현 객체는 자신의 로직을 실행하는 역할만 담당한다.
  프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다.
  이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.

프레임워크 vs 라이브러리

• 프레임워크가 내가 작성한 코드 제어하고, 대신 실행하면 프레임워크(JUnit)
• 내가 작성한 코드가 직접 제어의 흐름을 담당하면 라이브러리

의존 관계 주입 DI(Dependency Injection)

• 인터페이스에만 의존하여 실제 어떤 구현 객체가 사용될지 모른다.
• 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존관계 둘을 분리해서 생각해야한다.
• 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

정적인 클래스 의존관계
: import 코드만 보고도 쉽게 알 수 있다. 실행하지 않아도 분석할 수 있다.
그러나 이 의존관계로만으로 실제 어떤 객체가 주입될지 알 수 없다.

동적인 객체 인스턴스 의존관계
: 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

Ioc 컨테이너, DI 컨테이너

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 혹은 DI 컨테이너라고 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.