정의
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
Dependency Inversion Principle(이하 DIP)의 정의는 위와 같이 2가지가 있습니다. 번역을 해보면 high-level 모듈은 low-level 모듈에 의존해서는 안되고 둘 다 abstraction에 의존해야 하며 abstraction은 detail에 의존해서는 안되고 detail이 abstraction에 의존해야 한다는 뜻입니다.
High-level module과 Low-level module
DIP의 정의에서 high-level module과 low-level module이 있는 것을 볼 수 있습니다. 그렇다면 high-level module은 무엇이고 low-level module은 무엇일까요?
이를 알아내기 위해서는 우선 level에 대한 정의가 필요합니다. Uncle Bob은 Clean Architecture책에서 level의 정의가 다음과 같다고 했습니다.
A strict definition of “level” is “the distance from the inputs and outputs.”
Level의 정의는 I/O와 떨어진 거리입니다. 즉, I/O를 하는 module은 가장 low-level이며 다른 module들을 거칠수록 high-level이 된다는 의미입니다.
위의 그림에서 Translate module은 I/O 연산을 담당하는 Read Char module과 Write Char module로부터 1의 거리만큼 떨어져 있는 것을 볼 수 있습니다. 그러므로 해당 예제에서 가장 level이 높은 module은 Translate module입니다.
Clean Architecture와 DIP
이제 DIP의 정의에서 불명확한 것이 없어 보입니다. 그러면 DIP는 왜 사용하는 걸까요?
이는 clean architecture와 연관이 있습니다.
Clean architecture는 시스템을 layer로 나누어 관심사를 분리하는 것이 목적입니다. 이렇게 나뉜 layer들은 level이 존재하며 위 그림에서 안쪽으로 갈수록 high-level이며 바깥으로 갈수록 low-level입니다.
Clean architecture에서 dependency는 바깥 원에서 안쪽 원으로만 가져야 하는 dependency rule이 있다고 설명했습니다. 만약 dependency rule이 깨지는 상황에서는 DIP를 이용하여 dependency의 high-level layer가 low-level layer에 직접적으로 의존하지 않도록 해야 하며 그 이유는 아래와 같습니다.
-
재사용성
Entity layer와 use case layer는 business logic을 담고 있어서 동일한 business logic의 application들에서 재사용이 가능합니다. 하지만 해당 layer들이 low-level layer로의 직접적인 dependency를 가질 경우 재사용이 힘들어집니다.
예를 들어 entity layer가 android framework의 dependency를 가질 경우 해당 entity layer는 android application내에서만 재사용이 가능하게 됩니다. -
Low-level module의 변경에 대처 가능
Low-level module에 변경사항이 생길 경우 high-level module에 영향을 끼치지 않고 abstraction의 구현체를 변경하여 대처를 할 수 있습니다. 이는 open-closed principle과 연관이 있습니다. 단, abstraction에 변화가 생길 경우에는 high-level module에 영향을 끼칠 수도 있습니다.
Reference
[1] Robert Martin, Agile software development: principles, patterns, and practices (n.p.: Pearson, 2013), 127-134.
[2] Robert Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design (n.p.: Prentice Hall, 2017), 87-91, 183-187.
