IoC, DI, 그리고 컨테이너

스프링을 공부하다보면 IoC, DI, 컨테이너와 같은 단어를 많이 보게된다. 이는 우리가 이전 글에서 배운 개념을 생각하면 쉽게 이해 할 수 있다.

 

# IoC (Inversion of Control), 제어의 역전

• 기존에는 구현체가 필요한 다른 객체들을 직접 생성해서 연결하는 방식으로 만들었었다. 하지만 이런 방법은 감독이 아닌 공연배우가 상대 배우를 캐스팅하고, 소품을 준비하는 것처럼 혼자서 너무 많은 책임을 지고있다고 볼 수 있다.
• 우리는 이를 해결하기위해 AppConfig라는 구성영역을 만들어 여러 구현체를 생성, 주입하는 역할을 분리시켰다. 이제 실행영역에 있는 각각의 구현체들은 이제 더 이상 자신이 필요한 객체를 생성할 필요도 없고, 구현체가 바뀌었다고 해서 코드를 변경할 필요도 없다. 
• 즉 프로그램에 대한 제어 흐름에 대한 권한은 AppConfig가 가지고 있다. 서비스 실행영역은 묵묵히 자신의 로직을 실행할 뿐, 전체 제어 흐름에 대해서는 전혀 모른다.
• 이렇게 프로그램의 제어 흐름을 직접 제어하는 것이 아니라, 외부에서 관리하는 것을 제어의 역전(IoC) 라고 한다.

 

---

# 프레임워크 vs 라이브러리

보통 프레임워크과 라이브러리를 구분할 때 IoC 라는 말을 많이 사용한다. 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. 하지만 내가 작성한 코드의 전체 흐름을 내가 담당한다면, 그건 프레임워크가 아닌 라이브러리 인 것이다. (즉 테스트 라이브러리인 Junit도 일종의 프레임워크라고 볼 수 있다.)

 

---

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

의존관계 주입을 명확하게 이해하려면 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계를 분리해서 생각해야 한다.

 

@ 정적인 클래스 의존관계

클래스가 사용하는 의존관계는 import 코드만으로도 쉽게 판단할 수 있다. 이는 굳이 앱을 실행시키지 않아도 분석가능하다. 아래의 클래스 다이어그램을 통해 OrderServiceImpl은 MemberRepository와 DiscountPolicy에 의존한다는 것을 알 수 있다. 하지만 실제 실행에 어떤 구현체가 주입되고 어떻게 실행되는지는 알 수 없다.

 

@ 동적인 객체(인스턴스) 의존관계

앱 실행 시점에 생성된 인스턴스의 참조값이 연결된 의존관계이다.

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언
  트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
• 실제 동작은 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 호출하는 타입의 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 의존관계를 변경하지 않고, 동적인 인스턴스 의존관계를 변경할 수 있다. 

 

---

# IoC 컨테이너, DI 컨테이너

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 [ IoC 컨테이너 또는 DI 컨테이너 ]라 한다. 이 둘은 같은 말이지만, IoC는 범용적으로 사용되는 단어이기에 '의존관계 주입'에 초점을 맞춰 DI 컨테이너라고 부르게 된 것이다.

• 어플리케이션의 조립을 담당하는 컨테이너라는 의미로 어셈블러, 오브젝트 팩토리라고 불리기도 한다.

 

---

# 이제 스프링 프레임워크로로

앞에서는 톰캣 서버를 쉽게 띄우기 위해서 스프링부트를 이용했을 뿐, 전부 순수한 자바코드로 모든 객체들을 작성하였다. (스프링의 기능을 쓴 것이 없다.) 이제 다음 글에서 스프링 프레임워크는 앞의 개념들을 어떻게 지원하는지 직접 코드를 작성하며 알아보자.