[Spring] 2. 구성 영역의 분리와 DI(Dependency Injection)

 

 

 

 

* 김영한님의 스프링 핵심원리 기본편 강좌를 수강하며 정리한 글입니다. *

 

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

 

 

 

이전 글에서는 다형성(인터페이스)만으로는 OCP, DIP를 지킬 수 없는 이유를 정리하였다.

이번에는 이를 해결할 수 있는 구성 영역과 실행 영역의 분리, 그리고 DI(Dependency InJection)과 컨테이너 기술을 살펴보자.

 

 

생성자 주입과 DI(의존관계 주입)

 

 

역할(배역, 인터페이스)과 구현(배우, 구현체)을 분리했다면, 구현체가 다른 역할의 구현체를 직접 선택하는 것은 배우가 직접 상대 배우를 선택하는 책임도 지는 것과 같다.

구현체는 본연의 역할, 책임에만 집중해야 한다.

따라서 역할에 맞는 구현체를 지정하는 책임을 가지는 기획자 역할이 필요한 시점이다.

 

구현 객체를 생성하고 연결해주는 책임을 가지는 기획자 class,  AppConfig를 구현해보자.

 

 

기존의 OCP, DIP가 문제 되었던 코드에서는 직접 구현체를 선택해서 의존하고 있다.

 

 

이런 작업을 AppConfig가 담당하도록 바꾸어 주자.

MemberRepository 구현체의 변경이 필요하면 AppConfig에서만 교체해주면 됨

 

생성자를 통해 memberRepository를 넣어주고 있다. 구현체 의존은 전혀 없다.

 

이처럼 MemberServiceImpl 생성자를 통해 AppConfig가 생성한 객체 참조값이 들어가는 것을 생성자 주입이라고 한다.

이를 통해 구현체 내 코드에서 다른 역할의 구현체 의존을 없애고 오직 interface 코드로 작성이 가능하다.

따라서 구현체는 DIP를 따르고 있고 기능 실행의 책임만, 의존 관계의 설정은 AppConfig가 담당한다.

 

 

 

의존관계 주입

 

클라이언트(MemoryServiceImpl)는 의존 관계를 외부에서 주입받는다 하여 DI(Dependency Injection) 의존관계 주입, 의존성 주입이라고 한다.

 

 

 

이제 실행할 때 객체들은 AppConfig를 통해 생성하면 된다.

 

 

 

구성 영역과 사용 영역의 분리

  

구성 영역의 코드만 바꾸어서 역할을 담당하는 구현체 변경이 가능하다.

사용 영역(클라이언트 코드)에는 어떠한 영향이 없다.

따라서 OCP, 확장에는 열려있지만 변경에는 닫혀 있게 된다.