의존성 역전 원칙 (DIP, Dependency Inversion Principle)
모든 소프트웨어 시스템, 혹은 작은 애플리케이션이라도 Layer가 존재합니다.
어떻게 Layer를 구성하며, 각 Layer마다 의존관계는 어떻게 이루어져야하는지에 대한 원칙이 있습니다.
큰 원칙으로는
a. 상위수준의 모듈은 하위수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야한다.
b. 추상화는 구체적인 사항에 의존해서는안된다. 구체적인 사항은 추상화에 의존해야한다.
여기서 상위수준이란, 정책의사결정과 업무모델을 포함하는 층, 재사용하기 원하는것들, 어플리케이션의 본질을 담는층 혹은, 고객의 요구사항중 내재하는 추상화, 구체적인 것들이 변경되더라도 바뀌지않는 진실의 핵심적인 내용들이 있는 Layer를 상위수준 Layer라고 합니다.
이런모듈이 하위모듈을 의존하면 안된다고 합니다.
- 하위모듈은 구체적인 모듈을 의미하며, 하위수준의 구체적인 모듈에 영향을 주어야하는 것은 정책을 결정하는 상위수준 모듈이어야합니다.
- 즉 상위수준의 모듈의 변경이 생겼을때, 하위수준의 모듈이 수정, 확장이 이루어지게 되도록 Layer를 구성해야합니다.
상위수준의 모듈이 하위수준의 모듈에 독립적이라면 이 상위수준의 모듈은 아주간단히 재사용 될 수 있습니다. 이 원칙은 프레임워크 설계의 핵십입니다.
위의 그림은 정책이 구체적인 Layer들에 의존하여 실패한 Layer 나누기의 예입니다.
이것을 어떻게 수정할 수 있을까요?
바로 의존성역전원칙을 사용하면 됩니다.
의존성역전원칙을 적용하실때는, 상위수준에서 하위수준에 의존할때 사용하던 메서드들을 인터페이스 뽑은다음, 그 인터페이스를 상위수준에서 의존하게끔 하게 만들면 됩니다. 그리고 그 인터페이스의 구현체는 하위수준Layer에서 구현을 해놓으면 됩니다.
위와같이 의존성이역전되게되면, Utilty Layer의 변화와 Mechanism Layer의 변화가 Policy Layer에게 변화를 안끼치게 됩니다.
여기서 명심하셔야 할 것은, 의존성역전의 결과로 인터페이스의 소유권이 어디있는지 주목 해보시기 바랍니다.
인터페이스는 되게 사용하는층에서 가져야 합니다.
대개 한번쯤은 유틸리티라이브러리가 그것의 고유인터페이스를 소유한것으로 생각하지만, DIP가 적용된 경우에는 클라이언트(사용하는쪽)가 추상 인터페이스를 소유하는 경향이있습니다.
DIP가 아직 무엇인지 이해가 안되신다면 추상화에 의존하자! 이 키워드만 꼭 기억하시기 바랍니다.
구체적인 클래스는 추상적인것에 의존할 수록 좋은것이고, 반대로 추상적인클래스가 구체적인클래스에 의존하면 설계가 실패했다고 생각하시면 됩니다.
이제 간단한 예제2개를 살펴보도록 하겠습니다.
먼저 Button에서 감지한것을 바탕으로 외부객체에 반응을 내보내는 시스템을 만든다고 가정해보겠습니다.
흔히들 처음 목표는 아래그림처럼 버튼눌렀을때 램프를 켜는 시스템을 만들어주세요! 라고 요청이 왔을 것입니다.
하지만 이러한 요구사항에 앞서서 한번더 상위모듈 (정책, 변하지않는 메타포, 추상화) 을 생각해봅시다.
추상화를 좀 더 들어간다면, 버튼이라는것이 눌렸을때, 어떤 대상이 되었건 동작이 발생해야한다가 추상적인 개념이며 이 시스템의 상위모듈에 위치해야합니다.
즉 아래처럼 Lamp를 의존성 역전을 시켜서 버튼의 반응이왔을때 그것이 램프든, CCTV든 Motor든 어떤 외부객체라도 호출할 수 있도록 할 수 있습니다.
역시 인터페이스를 하나 만들고, 상위모듈에 두며, 그 인터페이스의 구현체는 하위모듈에 가는 방식으로 Layer가 나뉘게 됩니다.
또다른 예제를 살펴보겠습니다. 레귤레이터 시스템이 있고, 현재온도에따라 히터를 틀어주거나 끄거나 하는 시스템이 있다고 가정해봅시다. 구체적인 온도계와, 히터는 밑의 하위모듈로 내리고, 상위모듈에서는 추상적인 인터페이스들로 비즈니스로직을 구성하도록하면, 상위모듈은 하위모듈에 영향을 안받게 됩니다.
유튜브 강의링크