DI (Dependency Injection)가 뭘까?

의존관계

DI를 알아보기 이전에 의존(Dependency)이라는 키워드에 대해서 알아봅시다. 예를들어, A라는 클래스가 B라는 클래스를 내부적으로 사용하게 되면 A는 B에게 의존하는 관계입니다. UML으로 표시하면 아래와 같습니다.

출처 : http://www.cs.utsa.edu/~cs3443/uml/uml.html

위의 UML을 보면 Person이라는 클래스가 Book이라는 클래스를 내부적으로 사용합니다. 그리고 Book이라는 클래스를 점선 화살표로 가르키게 되는데 이러한 관계를 Person이 Book에게 '의존'한다 라고 합니다. (추가적으로, DI를 처음 배울 때 이상한 점이 있었습니다. 스프링의 DI관계를 자세히 보면, 의존보다는 엄밀히 말해 '연관'이 맞다고 생각했습니다. 근데 왜 의존이라고 하는지 의아했는데, 연관은 의존에 좀 더 강한 표현이기 때문에 의존이라는 표현을 사용해서 포괄적으로 나타내기 위함입니다.) 

DI(Dependency Injection)이란?

DI는 앞서서 설명한 클래스간의 의존관계를 설정해주는 일을 합니다. DI를 구현하기 위해서는 A라는 클래스가 B라는 클래스를 의존한다고 하여도, A라는 클래스는 B의 구체 클래스가 아닌, B의 인터페이스에 의존하게 만듭니다. 그리고 실제로 A클래스에게 B구체클래스를 설정해주는 일은 외부에서 진행됩니다. (여기서 말하는 외부는 스프링에서 Bean 컨테이너를 말합니다.) 이런식으로 의존 관계를 설정한다고 하여 Injection이라는 키워드와 함께 DI라는 용어가 나오게 됩니다. (이러한 구조는 디자인 패턴의 '전략 패턴'과 같습니다. 전략패턴의 자세한 내용은 이전 포스팅에 있습니다. ☞ 전략 패턴 (strategy pattern))

DI를 하면 뭐가 좋을까요?

DI는 위에서 설명한 '전략 패턴' 이라는 디자인 패턴 구조를 가지고 있습니다. DI를 함으로써 얻는 장점은 전략 패턴을 구현한 장점과 같습니다. 의존하고 있는 클래스가 변경이 되더라도 구체클래스가 아닌 인터페이스를 통해서 의존하고 있기 때문에, 구체클래스를 바꾸고 싶다면, 의존설정시에 다른 구체클래스만 명시하면 됩니다. 이런식으로 의존관계를 설정하게 되면 객체지향 설계 원칙인 OCP(개방 폐쇄 원칙)과 DIP(의존 역전 원칙)을 자연스럽게 따르게 됩니다. 결합도가 낮아지게 되어서 유지보수와 확장에 유리한 이점을 갖게 됩니다.

<전략 패턴을 나타낸 UML>

여러 전략 (Strategy)가 있더라도 인터페이스에 의존하고 있기 때문에 다양한 전략(Strategy)으로 쉽게 변경이 가능해집니다. 예를들면 테스트시에 테스트 전용 의존 객체를 삽입하기도 쉽고, 추후 다른 기능에 의존하게 되더라고 코드에 변화는 최소화하면서 '확장'이 가능해집니다. 유연한 애플리케이션 구조가 되는 것입니다.