DI

DI는 Dependency Injection 

의존관계 주입이라고 한다.

 

이를 이해하기 위해서 먼저 의존관계라는 것을 알아보자.

 

의존관계는

정적인 클래스 의존관계 / 실행 시점에 결정되는 동적인 객체(인스턴스) 의존관계로 분리할 수 있다.

 

정적인 클래스 의존관계는 import 코드만 보고 쉽게 판단할 수 있는 것이다.

정적인 의존관계는 어플리케이션을 실행하지 않고도 알 수 있다.

 

예를 들어,

위 코드에서 import 부분을 보면 DiscountPolicy, Member, MemberRepository가 사용된다는 것을 알 수 있다.

여기에서의 의존관계는 인텔리제이 다이어그램으로도 확인할 수 있다.

 

 

이제 실행 시점에 결정되는 동적인 객체 의존관계를 확인해 보자.

현재 위 코드만 봐서는 OrderServiceImpl에 어떤 객체가 주입이 될지는 알 수 없다.

생성자 부분에서 memberRepository에 뭐가 들어올지 모르고 discountPolicy에 뭐가 들어올 지 모르는 상태라는 것이다.

이것은 실행을 시켜봐야 알 수가 있다.

 

위와 같은 코드를 통해서 discountPolicy에 ratediscountpolicy를 기획자가 fixdiscount로 바꾸고 싶다고 요청하면 

나는 fixdiscountpolicy 코드를 제작해 리턴되는 값을 fixdiscountpolicy로 바꿀 수도 있다.

이러한 변경 사실은 appconfig를 봐야 아는 것이지, 이전의  OrderServiceImpl코드만 봐서는 알 수 없다.

 

이렇게 객체의 의존관계을 개발자가 아니라 외부(DI containder. 예시에서는 Appconfig)에서 주입하는 것을 의존관계 주입, DI라고 한다.

좀 더 정리하면 아래처럼 말할 수 있다.

어플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결되는 것을 의존관계 주입이라고 한다.

 

이렇게 의존관계 주입을 사용하면,

- 클라이언트 코드를 변경하지 않고도 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
 (rateDiscount를 fixDiscount로 변경하는 것을 생각한 예시)

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

(내가 rateDiscount를 fixDiscount로 바꾼다고 해서 아래 그림이 바뀌지 않는다.)