소프트웨어 설계5원칙 『의존성역전 DIP』

SOLID의 마지막은 의존성역전 원칙이다.

의존성 역전? 말이 상당히 난해하다. 

 

 

결론적으로 의존성역전 원칙을 위배한 상황은

자동차에 운전대 2개를 붙여놓은 설계를 예로 들 수 있다.

 

바보같은 질문이지만

운전대 2개가 있는 자동차는 잘 움직일까?

아마도 누가 운전자가 되건, 변경(상대의 조작)에 취약할 수 밖에 없을 것이다.

 

좋은 소프트웨어 설계는

저수준 모듈(레벨)이 고수준 모듈을 침범하지 않는다.

즉, 의존관계가 확실하기 때문에

조수석에서 차량 운행에 관여할 수 없다.

 

 

│인터페이스

 

더 깊게 들어간다면,

운전자는 운전석에서 자동차의 고수준 정책(엔진마력, 토크, 냉각수 등)에 직접 관여할 수 없다.

운전자가 조향, 제동, 가속, 변속 등과 같은 기능을 사용하려면,

핸들, 브레이크, 악셀레이터, 기어 or 버튼과 같은 인터페이스를 거쳐야만 한다.

 

 

운전자는 인터페이스를 통해서만 고수준 정책(핵심)에 접근할 수 있다.

또, 고수준 모듈(엔진) 역시 인터페이스를 거쳐야만 운전자와 만날 수 있다.

 

즉, 운전자는 인터페이스에 의존하며,

기계(엔진 및 기타)도 역시 인터페이스에 의존한다.

 

이는 운전자, 엔진 모두 인터페이스(핸들,브레이크,악셀, 기어 등)에 의존한다고 할 수 있으며,

덕분에 운전자, 엔진이 변경되더라도 인터페이스는 그대로 유지될 수 있다.(외부변화에 무관)

 

   그리고 운전면허가 있는 사람은

각기 다른 업체에서 제작한 차를 모두 운전할 수 있다.

(인터페이스는 그대로이므로)

 

 

 

│의존성역전 원칙

의존성역전 원칙은 결국 인터페이스에 관련된 개념이며,

추상화를 통해 인터페이스를 설계하는 일이 전부다. 

그래서 좋은 소프트웨어는 다음 질문에 대한 고민이 코드에 드러난다.

 

어떻게해야 의존관계를 역전하지 않을까?

 

위의 다이어그램을 보자.

참고사항으로 다이어그램 화살표의 의미는 다음과 같다.

---

A → B

① A는 B를 사용한다. [제어]

② A는 B에 의존한다. [의존]

 ③ B는 A의 변경과 무관하다. [보호] 

---

다이어그램에서 화살표 방향은

『제어』 『의존』 『보호』

3가지를 나타낸다.

 

위의 다이어그램에서 운전자를

저수준 레벨의 모듈이라고 한다면,

엔진·미션 Class는 운전자가 바뀔 때마다

영향을 받게 되고, 이런 시스템은 오래가지 못한다.

 

 

위의 사진과 같은 상황은 현실에서 거의 불가능하지만

교과서적으로 보자면, 운전자(저수준 레벨)가 수동으로

직접 엔진을 조작하고 있는 상황이다.

 

운전자는 엔진에 의존함과 동시에 엔진을 제어하고,

엔진은 운전자가 변경될 때마다 영향을 받는다.

 

이를 해결하기 위해서는 '추상화'가 필요하다.

 

 

│인터페이스 생성 『추상화』

다시 자동차 계기판을 생각해보자.

자동차 계기판은 그 자체로 아무런 기능도 없다.

그냥 플라스틱 껍데기에 불과하다.

 

다만, 인터페이스로써 매개체 역할을 수행한다.

 

위와 같이 설계를 한다면,

운전자는 인터페이스를 제어하고,

동시에 인터페이스에 의존한다.

또, 인터페이스는 운전자가 바뀌더라도 상관없다. 

 

엔진 역시 인터페이스에 의존하면서 동시에 제어한다.

(ex.엔진경고등 켜기)

 

그리고 인터페이스는 엔진의 고장(변경)을

표시만 할뿐 직접적인 영향을 받지 않는다.

 

결론적으로 인터페이스에 의해

의존성 역전현상이 발생하면서

상위 레벨이 하위 레벨(운전자)에 종속되는 상황이 해결된 것이다.

 

 

SOLID원칙 중에서도

의존성역전, 개방-폐쇄 원칙은

컴포넌트, 아키텍처 단계에서도 항상 염두에 둬야 할 부분이다.

 

For.좋은 소프트웨어