IoC, DI와 컨테이너

IoC(Inversion of Control)

---

프로그램의 제어 흐름을 사용자가 직접 제어하는 것이 아니라

외부(프레임워크)에서 관리하는 것을 제어의 역전이라고 한다. DI를 가능하게 하는 기반 기술

 

『스프링이 제어의 역전을 구현하는 방법』

스프링 프레임워크에서는 ApplicaionContext가 이 역할을 담당하며, @ComponentScan annotation은 지정된 패키지 내의 @Component annotation이 붙은 클래스를 자동으로 스캔하고 빈으로 등록한다.

 

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

" 프레임워크는 "프레임"이라는 말처럼 틀을 만들어두고 개발자로 하여금 사용 방법을 강제하는 것에 반해, 라이브러리는 개발자가 좀 더 자유롭게 사용할 수 있는 코드 조각 모음이다."  -  프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다  -  개발하면서 반복되는 코드들을 어떤 규칙에 맞게 쓸 수 있도록 환경을 구성해 놓은 것, 라이브러리와 차이점은     개발자가 작성한 코드가 프레임워크에 의해 수동적으로 불려진다는 점이 차이점이다  -  반면, 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임 워크가 아니라 라이브러리이다.     발하면서 반복되는 코드들을 모아놓은 것 남이 만들어진 코드를 기반으로 개발을 할 수 있어서 생산성이 증가한다     라이브러리는 개발자가 능동적으로 호출할 수 있다

 

DI(Dependency Injection)

---

외부에서 두 객체 간 관계를 결정해주는 디자인 패턴으로,

인터페이스 사이에 둬서 클래스 레벨에서는 의존관계가 고정되지 않도록 하고, 런타임 시에 관계를 동적으로 주입하여, 유연성을 확보하고 디커플링을 할 수 있게 해준다.

 

DI로 객체지향의 원칙인 DIP OCP SRP 가 커버가 된다.

 

"정적인 클래스 의존관계"와 "런타임 시 결정되는 동적인 객체 의존 관계"를 분리하는 것,

 

<정적인 클래스 의존관계>

OrderServiceImpl 구현체는 MemberRepository와 DiscountPolicy 라는 인터페이스를 import 하고 있지만, 실제 어떤 인스턴스를 쓰는지는 "정적인 클래스 의존관계"에서는 알 수 없다. 

 

<동적인 객체 인스턴스 의존 관계>

(외부 구성 영역인 AppConfig 에서 DiscountPolicy 인터페이스 중 FixDiscountPolicy 구현 객체를 생성하고, 연결하는 책임을 가짐)

 

위 AppConfig의 기능으로 런타임때 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계를 연결 되는 것을 의존관계 주입이라고 한다.

 

의존 관계 주입을 사용하면, 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계만 쉽게 변경할 수 있다.

 

※ IoC 컨테이너 / DI 컨테이너 

 - 위 AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것

 -  Assembler, Object Factory 라고도 한다.

 

 

---

출처: https://inf.run/kCYMv

스프링 핵심 원리 - 기본편 강의 | 김영한 - 인프런