IoC, DI, 그리고 컨테이너

1️⃣ 제어의 역전

IoC, Inversion of Control

• 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고(new로 직접 생성), 연결하고, 실행했다.
• 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름을 AppConfig가 가져간 것이다.
  • 클라이언트 객체는 필요한 인터페이스들을 호출하지만 어떤 구현 객체가 실행될지는 모른다.
  • 프로그램에 대한 제어 흐름은 모두 AppConfig가 가지고 있게 된다.
• 이렇듯 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라 한다.

This chapter covers the Spring Framework implementation of the Inversion of Control (IoC) principle. IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies (that is, the other objects they work with) only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method.

이 챕터에서는 스프링 프레임워크의 Inversion of Control(IoC) 원칙 구현에 대해 설명합니다. IoC는 객체가 자신의 종속성(함께 작동하는 다른 객체)을 다음의 방법들을 통해서만 정의하는 프로세스입니다
➡️ 생성자 인자, 팩토리 메소드의 인자, 객체 인스턴스가 생성되고 나서, 또는 팩토리 메소드에서 리턴되고 나서 설정된 프로퍼티 -  Spring Framework의 Core 문서

In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. Beans, and the dependencies among them, are reflected in the configuration metadata used by a container.

Spring에서 애플리케이션의 중추를 이루고 Spring IoC 컨테이너에 의해 관리되는 객체들을 Bean 이라 부릅니다. Bean은 Spring IoC 컨테이너가 인스턴스로 만들고, 조립하고, 관리하는 객체입니다. 한편으로는, Bean은 당신의 애플리케이션 안에 있는 수많은 객체들 중 하나일 뿐이기도 합니다. Bean과 Bean들 사이의 종속성은 컨테이너가 사용하는 configuration metadata에서 반영됩니다.

 

 

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

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

The major difference between an object-oriented framework and a class library is that the framework calls the application code. Normally the application code calls the class library. This inversion of control is sometimes named the Hollywood principle, "Do not call us, we call You".

객체지향 프레임워크와 클래스 라이브러리의 큰 차이점은 프레임워크가 애플리케이션 코드를 호출한다는 것입니다. 일반적으로는 애플리케이션 코드가 클래스 라이브러리를 호출합니다. 이러한 제어의 역전(inversion of control)은 때때로 헐리우드 원칙이라고도 합니다. "우리에게 전화(call)하지 마세요. 우리가 당신을 부를(call) 것입니다" - Michael Mattson의 논문 Conclusions (98쪽) 

 

 

3️⃣ 의존관계 주입

DI, Dependency Injection

• 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계를 분리해서 생각해야 한다.
  • 정적인 클래스 의존관계는 클래스가 사용하는 import 코드만 보고도 판단할 수 있다. 즉, 애플리케이션을 실행하지 않아도 분석할 수 있다. 하지만 이러한 클래스 의존관계만으로는 실제로 어떤 객체가 인터페이스에 주입 될 지 알 수 없다.
• 애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라고 한다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

한 가지 짚고 넘어갈 것은 여기서 사용하는 IoC라는 용어인데, IoC가 매우 느슨하게 정의돼서 폭넓게 사용되는 용어라는 점이다. 때문에 스프링을 IoC 컨테이너라고만 해서는 스프링이 제공하는 기능의 특징을 명확하게 설명하지 못한다. 스프링이 서블릿 컨테이너처럼 서버에서 동작하는 서비스 컨테이너라는 뜻인지, 아니면 단순히 IoC 개념이 적용된 템플릿 메소드 패턴을 이용해 만들어진 프레임워크인지, 아니면 또 다른 IoC 특징을 지닌 기술이라는 것인지 파악하기 힘들다. 그래서 새로운 용어를 만드는 데 탁월한 재능이 있는 몇몇 사람의 제안으로 스프링이 제공하는 IoC 방식의 핵심을 짚어주는 의존관계 주입(Dependency Injection)이라는, 좀 더 의도가 명확히 드러나는 이름을 사용하기 시작했다. 스프링 IoC 기능의 대표적인 동작원리는 주로 의존관계 주입이라고 불린다. 물론 스프링이 컨테이너이고 프레임워크이니 기본적인 동작원리가 모두 IoC 방식이라고 할 수 있지만, 스프링이 여타 프레임워크와 차별화돼서 제공해주는 기능은 의존관계 주입이라는 새로운 용어를 사용할 때 분명하게 드러난다. 그래서 초기에는 주로 IoC 컨테이너라고 불리던 스프링이 지금은 의존관계 주입 컨테이너 또는 그 영문약자를 써서 DI 컨테이너라고 더 많이 불리고 있다

- 토비의 스프링 3.1 vol 1. 1.7.2장. 111쪽. 

 

 

4️⃣ IoC / DI 컨테이너

• AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너 혹은 DI 컨테이너라고 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라고 한다.
• 어셈블러, 오브젝트 팩토리 등으로 불리기도 한다.

 

 

결론

• 제어의 역전 
  • 프로그램의 제어 흐름을 직접 제어하는 게 아니라 외부에서 관리하는 것 -> 프레임 워크는 제어의 역전이 적용 된 것. 
  • Spring에서는 객체가 자신의 종속성을 생성자 인자, 팩토리 메서드의 인자, Setter method 로만 정의하는 프로세스라고 정의. 
• 의존관계 주입 
  • 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것. 
  • Spring이 제공하는 IoC의 방식의 핵심을 짚어주는, 좀 더 명확한 의도가 담긴 용어

 

👍 Reference

https://inf.run/uCYa

https://johngrib.github.io/wiki/inversion-of-control/

https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/beans.html