의존관계 주입(DI Dependency Injection)

IoC는 소프트웨어에서 자주 발견할 수 있는 일반적인 개념

매우 느슨하게 정의돼서 폭넓게 사용되는 용어

때문에 스프링을 IoC 컨테이너라고만 해서는 스프링이 제공하는 기능의 특징을 명확하게 설명하지 못한다.

 

• 스프링이 서블릿 컨테이너처럼 서버에서 동작하는 서비스 컨테이너라는 뜻인지
• 단순히 IoC 개념이 적용된 템플릿 메소드 패턴을 이용해 만들어진 프레임워크인지
• 또 다른 IoC 특징을 지닌 기술이라는 것인지

그래서 새로운 용어를 만드는데 탁월한 재능이 있는 몇몇 사람의 제안으로 스프링이 제공하는 
IoC 방식의 핵심을 짚어주는 의존관계 주입 (Dependency Injection) 이라는, 좀 더 의도가 명확히

드러나는 이름을 사용하기 시작했다.

 

* 의존관계 주입, 의존성 주입, 의존 오브젝트 주입?

Dependency Injection 은 여러 가지 우리말로 번역돼서 사용된다.

그중에서 가장 흔히 사용되는 용어가 '의존성 주입'

하지만 의존성이라는 말은 DI의 의미가 무엇인지 잘 드러내주지 못한다.

또한, 의존(종속) 오브젝트 주입이라고도 부르기도 하는데, 이때는 DI가 일어나는 방법에 초점을 맞춘 것이다.

엄밀히 말해서 오브젝트는 다른 오브젝트에 주입할 수 있는게 아니다.

단지 오브젝트의 레퍼런스(참조)가 전달될 뿐이다.

 

DI는 오브젝트 레퍼런스를 외부로부터 제공(주입)받고 이를 통해

여타 오브젝트와 다이내믹하게 의존관계 만들어지는것이 핵심이다.

 

[의존관계]

• 두 개의 클래스 또는 모듈이 의존관계에 있다고 말할 때는 항상 "방향성"을 부여해줘야 한다.
• A가 B에 의존하고 있다고 할 때,
  B가 변하면 그것이 A에 영향을 미친다는 뜻
• 즉 B의 기능이 추가되거나 변경되거나 형식이 바뀌면 그대로 그 영향이 A로 전달된다는 것

 

[정리]

• 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않는다.
  그러기 위해서는 인터페이스에만 의존하고 있어야 한다.
• 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제3의 존재가 결정한다.
• 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공(주입)해줌으로써 만들어 진다.

 

[핵심]

설계 시점에는 알지 못했던 두 오브젝트의 관계를 맺도록 도와주는 제3의 존재가 있다.