DI(Dependency Injection)

출처: https://dotnetpower.tistory.com/29 [닷넷파워의 프레임웍 이야기 - 문제는 기술이 아니라 사람이다]

DI(Dependency Injection) ; 종속객체 주입이란?

OOP(Object Oriented Programming)의 우수함과 유연성 덕분에 프로그래밍 언어는 대부분이 이와 같은 성격을 띄고 있다.
객체지향이 완벽할것이라 생각을 했지만, 어플리케이션의 덩치가 커질수록 어쩔수 없는 결합도(Coupling)가 생겨 버린다.
결합도 라는 말은 모듈들 사이의 관계를 말한다. 모듈이 독립적일수록 결합도가 낮다고 말할수 있고, 결합도가 낮을수록 좋은 프로그램 이라고 말한다. 느슨하게 결합된 디자인은 변경사항이 생겨도 큰 무리 없이 수정이 가능 해 진다.

하지만, 결합도 라는것은 아무리 느슨한 결합도(Loose Coupling)를 유지해도, 런타임시에 요청 -> 응답 까지는 연결될수 밖에 없다. 결합도를 조금이라도 낮추기 위해서 인터페이스를 사용하는데 이걸로도 해결되지 않는 문제가 있다.

DI는 보통 역제어(inversion of control) 이라는 이름으로 2004년 Martin Fowler에 한 논설에서 제어의 어떤 측면이 역전(invert)되는지 의문을 가지고 구체적으로는 종속객체를 획득하는 부분이 역전된다는 결론을 내리고 "종속객체 주입" 이라는 용어를 고안해 내었다고 한다. -Spring in Action 참고-

보통 위 그림처럼 ClassA는 ServiceA, ServiceB와 결합도를 유지 하게 된다.

이렇게 설계가 되었을때 다음과 같은 상황이 발생되어진다.

• 관계가 변경되거나 수정되어야 할때 반드시 소스코드를 수정해야한다.
• 컴파일 될때 관계가 겹합되어 버린다.
• 단위 모듈별 테스트를 하기 어렵다.
• 클래스 들이 반복적으로 생성되고, 재 배치된다.

그렇다면 DI를 사용하면 어떻게 결합도를 낮출수 있을까?
이에 대해 해결할수 있는 방법은 객체를 주입 시켜 버리면 된다. 아래 그림 참고.

우선 Builder라는것은 컴파일 되는 시점이라 생각하면 될것 같다.
컴파일 될때 ClassA를 생성시키고, ClassA는 ServiceA, ServiceB 의 인스턴스를 생성하는 것이 아니라  생성시점에서 Builder로 부터 주입되어진다. 그리고 나서 사용 할때는 Service들의 인터페이스를 통해 주입되어진 Service들을 사용 할 수 있다. 이것이 바로 역제어(inversion of control) 라 한다.

보통 Dependency Injection 를 위해서는 다음과 같은 방법이 존재 한다.

• 생성자를 이용한 의존성 삽입(Constructor Injection)
• Setter() 메소드를 이용한 의존성 삽입(Setter Injection)
• 초기화 인터페이스를 이용한 의존성 삽입(Interface Injection)

출처: https://dotnetpower.tistory.com/29 [닷넷파워의 프레임웍 이야기 - 문제는 기술이 아니라 사람이다]