3부 설계원칙-DIP

DIP란?

상위 레벨의 로직은 저수준의 로직에 절대 의존해서는 안된다. 대신 저수준의 로직이 고수준에 의존해야 한다.

 

DIP의 사용 이유

변경으로 부터 보호

위 그림은 절차적 프로그래밍의 런타임 플로우와 소스코드의 의존성을 표현한 그림이다.  소스코드의 의존성과 런타임 플로우가 같은 방향으로 내려같은 것이 같다. 위 그림과 같다면 LL1의 변경은 ML1의 변경으로 이어지고 또 HL1그리고 마지막으로 Main의 변경으로 이어질 것이다. 이는 상위 로직이 하위 로직에 의존하기 때문이다.

 위 그림과 같이  DIP를 적용하면 ML1하위에서의 변경 사항은 HL1에 영향을 주지 않는다. 이처럼 DIP를 사용하면 변경 사항으로 부터 보호 할 수 있다. 즉 상위 정책은 저수준의 세부 로직에 의존하지 않기 때문에 생기는 이득이다.

 

경계 생성

.

 

  위 그림을 보면 Application이라는 고수준의 정책이 ServiceFactory와 Service라는 인터페이스만을 의존하고 빨간선 아래에서 상속을 받고 생성하는 것이 보인다. 여기서 빨간선은 아키텍처의 경계를 뜻한다. 이처럼 보호받아야하는 고수준의 아키텍처를 추상 컴포넌트로 만들고 구체적인 세부사항을 구체컴포넌트에서 생성하여 추상컴포넌트 쪽으로 의존성을 만들 수 있다. 여기서 주의깊게 봐야 할 점은 의존성의 방향이 추상컴포넌트에서는 나가는 방향이 없고 구체 컴포넌트에서는 추상컴포넌트 방향으로 나아간다는 것이다.

 

구체 컴포넌트

DIP를 모든 컴포넌트에 적용 할 수 있는 것은 아니다.(대표적으로 Main이 있다.) 예를 들어 위 그림에서 ServiceFactory Impl은 ConcreateImpl에 의존한다. 이는 Dip에 위배된다. 하지만 위와 같이 컴포넌트를 분리함으로써 실제로 이런 Dip를 위배하는 클래스를 구체 컴포넌트로 모을 수 있고, 이를 통해 나머지 부분과 분리 할 수 있다