이번 포스트에서는 SOLID 원칙의 마지막인 DIP 에 대해서 예시와 함께 다뤄보려고 한다.
DIP (Dependency Injection Principle)
DIP 는 Dependency Injection Principle 의 약어로, 의존성 역전 원칙을 의미한다. DIP 의 개념은 다음과 같다.
Depend upon abstractions, [not] concretions.
A. High-level modules should not import anything from low-lovel modules. Both should depend on abstraction (e.g., interfaces).
B. Abstraction should not depend on details. Details (concrete implementations) should depend on abstractions.
구체화에 의존하지 말고, 추상화에 의존해라.
A. 고수준 모듈은 저수준 모듈의 어떤 것도 import 해선 안된다. 둘 다 추상화에 의존해야 한다.
B. 추상화는 구체적인 것에 의존하면 안된다. 구체적인 것(구현)은 추상화에 의존해야 한다.
다소 길긴 하지만, 상세 내용이 아닌 첫 번째 문장으로 요약할 수 있다. 최대한 추상화된 것에 의존하라는 것이다. DIP 역시 예시를 통해 이해해보자.
DIP 위반 시 생기는 문제점
OCP 에서도 다뤘던 예시를 확장해보려고 한다. Fig1 과 같이 설계했을 때 어떤 문제점이 생길 수 있는지 알아보자.
FlowController 는 Byte 소스의 흐름을 제어하는 단일 기능 수행을 목적으로 하는 고수준 모듈이고, 이는 파일 형태의 Byte 를 읽어오는데 사용되는 저수준 모듈에 의존하고 있다.
만약 이 경우 FlowController 가 다른 형태의 Byte 를 읽어오는 기능을 추가 혹은 삭제할 때 마다 FlowController 가 변경되어야 한다. 만약 FileByteSource 가 FlowController 가 아닌 다른 클래스에서도 이렇게 사용하는 클래스가 많다고 한다면, 다른 형태의 Byte 를 읽어오는 기능이 추가 혹은 삭제될 때마다 변경해야하는 양은 더 늘어난다.
DIP 원칙 따르기
고수준 모듈과 저수준 모듈이 Fig2 와 같이 추상화에 의존하게 한다면 기능이 추가 혹은 삭제될 때 고수준 모듈, 저수준 모듈 둘 다 변경에 닫혀있게 된다.
Fig2 에서는 고수준 모듈인 FlowController 와 저수준 모듈인 FileByteSource 가 추상화된 ByteSource 에 의존하고 있는 것을 볼 수 있다.
지금까지 살펴본 원칙도 함께 생각해보면, DIP 를 지키는 것과 LSP 를 지키는 것이 결국 OCP 를 지킬 수 있는 기반을 마련해주는 것이기도 하다.
결합도를 낮춰주는 DIP
DIP 는 고수준 모듈과 저수준 모듈의 결합도를 낮춰주기도 한다. Fig1 에서는 고수준 모듈인 FlowController 가 저수준 모듈인 FileByteSource 에 의존하기 때문에 저수준 모듈이 추가될 때마다 추가되는 저수준 모듈 역시 고수준 모듈과 결합성이 생긴다.
그러나 Fig2 와 같이 DIP 를 따르도록 설계하면 고수준 모듈은 저수준 모듈에 대해 알 필요가 없어지고, 저수준 모듈은 고수준 모듈에 결합성을 갖지 않는다.
SOLID 의 다른 원칙 바로가기
Reference
- 최범균, 2014, 객체지향과 디자인 패턴, 인투북스
- [Wikipedia] “SOLID” — https://en.wikipedia.org/wiki/SOLID
- [위키백과] “SOLID (객체 지향 설계)” — https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
