객체 지향 원리 적용: IoC, DI와 컨테이너란?

이 글은 김영한 님의 스프링 핵심 원리 - 기본편(https://inf.run/ZtdV)을 수강하며 정리한 글입니다.

 

 

IoC

제어의 역전(Inversion of Control)

 

 

프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것

기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.
(memberService 관련 구현체가 memoryMemberRepository를 직접 생성)

AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다.
프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다.
구현체는 묵묵히 자신의 로직을 실행할 뿐이다.

 

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

프레임워크: 내가 작성한 코드를 제어하고, 대신 실행 (JUnit)

• 개발자는 @Test 어노테이션 아래 테스트 코드를 작성했을 뿐
  실행과 제어권은 JUnit이라는 테스트 프레임워크가 가진다
  @BeforeEach 실행 후 @Test를 실행한다는 자신만의 사이클도 가진다 - 내가 작성한 코드는 그 중 하나일뿐
  MemberApp의 main메서드의 경우 개발자가 직접 제어한다 필요한 것은 new로 생성한다

라이브러리: 내가 작성한 코드가 직접 제어의 흐름을 담당할 때

• 자바 객체를 XML이나 JSON으로 바꾼다고 하면, 개발자의 의지로 그 라이브러리를 직접 호출한다

 

 

 

DI

Dependency Injection

 

 

생성자로 어떤 클래스의 객체를 전달받는 것

IoC 개념을 조금 구체화 시킨 것으로 객체 간의 관계를 느슨하게 해 준다.
(요구 사항의 변경에 유연하게 대처 가능해진다)

클래스 내부에서 다른 클래스의 객체를 생성하게 되면 두 클래스 간에 의존 관계가 성립하게 된다.

new를 사용해 참조할 클래스의 객체를 직접 생성하지 않고,
생성자 등을 통해 외부에서 다른 클래스의 객체를 전달 받고 있다면 의존성 주입이 이루어지고 있는 것이다.

 

🌳 정적인 클래스 의존관계

import 코드만 보고 쉽게 판단할 수 있다.
그런데 이러한 클래스 의존 관계만으로는 실제 어떤 객체가 OrderServiceImpl에 주입될지 알 수 없다.

 

🌳 동적인 객체 인스턴스 의존 관계

애플리케이션 실행 시점(런타임)에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고,
클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.

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

 

 

 

DI 컨테이너

IoC 컨테이너

 

 

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