스프링 설명회 - Dependency Inversion Principle

Dependency Inversion Principle

객체지향 설계원칙인 SOLID는 개발자에게 좋은 소프트웨어 설계의 방향성을 제공합니다. 의존성 역전 원칙은 SOLID 원칙 중 하나로, 고수준 모듈이 저수준 모듈에 의존하지 않고 추상화된 인터페이스에 의존하도록 설계하여 프로그램을 교체가능한 컴포넌트로 구성할 것을 권장합니다. 

Top-down Approach

구조적 프로그래밍의 핵심 가치 중 하나는 큰 문제를 여러 작은 문제로 나누어 해결하는 것 입니다. 나뉘어진 작은 문제는 다시금 여러 더 작은 문제로 나뉘어질 수 있습니다. 이렇게 나뉘어진 작은 문제는 큰 문제를 한 번에 해결하는 것보다 훨씬 간단할 뿐 더러, 잘 동작함이 증명된 채 재사용될 수 있습니다.

이렇게 분할하여 소프트웨어를 설계할 때, 큰 문제를 해결하는 모듈은 주로 프로그램의 주요한 정책 결정이나 비즈니스 모델을 담당하며 애플리케이션의 정체성을 형성합니다. 이러한 모듈을 고수준의 모듈이라고 이야기합니다. 한 편 작은 문제를 해결하는 모듈은 구체적인 동작과 세부적인 기능만을 담당하게 될 것이며, 이들을 저수준의 모듈이라고 합니다.

위 다이어그램은 위에서 설명한 분할 정복 기법을 사용한 소프트웨어 프로그램의 간략한 구조를 보여줍니다. 소프트웨어는 거대한 문제를 해결하기 위해 더 작은 문제를 해결할 수 있는 모듈을 호출함으로써 동작합니다. 다이어그램에서 볼 수 있는 것은 고수준의 모듈이 저수준의 모듈을 호출한다는 것입니다. 그리고 앞 글에서 알아봤다싶이, 호출한다는 것은 곧 의존관계를 만들어냅니다. 모든 고수준의 모듈은 저수준의 모듈에 의존합니다.

의존하면 곧 변경의 영향을 받습니다. f4가 변경되는 것은 f1와 f2의 변경을 초래하고, 이는 다시금 Main의 변경을 초래합니다. 저수준의 모듈 하나를 변경할 때 프로그램 전체에 영향이 퍼지는 문제가 발생합니다. 이러한 문제는 고수준의 모듈이 저수준의 구체적인 모듈을 알고 있으며 직접 호출함으로 동작하는 강한 결합 상태이기 때문에 발생합니다. DIP는 이러한 상황을 지적하며, 이를 해결할 수 있는 방법을 제시합니다.

Depends on Abstraction

위에서 다루는 예시를 작게 만들어 세 개의 모듈이 의존성을 갖는 상황을 가정해보겠습니다. Policy 클래스는 고수준의 모듈로 비즈니스 로직을 정의하며, Mechanism 클래스는 중간 계층으로 구체적인 동작을 수행하고, Utility는 저수준에서 공통기능 제공하는 도구로써 사용됩니다. Policy는 Mechanism을 사용하고, Mechanism은 Utility를 사용합니다.

이 구조는 문제를 해결하는 방법과 일치하는 직관적인 구조로 적절해 보이지만, 소프트웨어 설계에서는 문제가 될만한 부분이 존재합니다. 의존성은 전이하기 때문에 Policy와 같은 고수준 계층이 저수준의 계층의 변화에 민감하게 반응하는 상황이 발생합니다. Utility의 변경은 Mechanism의 변경을 초래하고, 이는 다시금 Policy의 변경을 초래합니다. 이는 바람직하지 않은 상황입니다.

의존성은 본질적으로 상대방을 알고 있기 때문에 발생합니다. 상대방을 모른다면, 의존할 수도 없습니다. DIP는 모듈이 추상에 의존하게 만드는 방식으로 사용하는 실제 모듈을 모르게 만듦으로써 의존성을 제거합니다.

위 다이어그램은 DIP가 적용된 클래스 다이어그램입니다. 이제 고수준 클래스는 저수준 클래스를 직접 사용하지 않습니다. 모든 저수준의 클래스들은 그들이 맡은 역할에 해당하는 추상화된 인터페이스를 구현하도록 강제되며, 고수준 클래스는 해당 인터페이스만을 의존합니다. 이렇게 추상을 통해 연결된 결합 관계를 약한 결합이라고 합니다.

위와 같은 설계를 통해 의존성의 전이를 제어할 수 있습니다. 이제는 DetailedMechanism 이 변경되는 경우, 다른 개체들에 변경을 초래하지 않습니다. DetailedUtility의 변경도 마찬가지 입니다. 물론 UtilityInterface가 변경되는 경우 DetailedMechanism과 DetailedUtility에 영향을 주겠지만, 인접한 클래스들에만 영향을 주고 그 외부의 다른 클래스들에는 영향이 퍼져나가지 않습니다. 

의존성 역전

DIP를 적용하기 전 구조에서 Policy는 Mechanism을 호출하고, Mechanism은 Utility를 호출하여 동작합니다. 고수준 모듈이 저수준 모듈을 직접 호출할 때, 제어의 흐름은 의존성의 방향과 동일합니다. Policy는 Mechanism에 의존하고, Mechanism은 Utility에 의존합니다.

한 편 DIP를 적용한 아키텍처에서 제어의 흐름은 기존과 동일하지만, 의존성의 방향은 제어의 흐름과 반대가 되었습니다. 더 이상 Policy가 Mechanism에 의존하는 것이 아니라, Policy가 갖고 있는 MechanismInterface에 DetailedMechanism이 의존합니다. 이렇게 의존성의 방향이 반대가 된 것을 의존성 역전(Dependency Inversion) 이라고 합니다.

Pluggable Architecture

인터페이스를 구현한 여러 구체 클래스가 존재한다면

서로 다른 오브젝트끼리 바꿔 끼워질 수 있다.

DIP가 적용되어 있는 구조에서는 프로그래밍은 상위 모듈이 사용하는 인터페이스를 하위 모듈이 구현하는 형태로 이루어집니다. 이 때 하위 모듈은 상위 모듈에 대한 플러그인처럼 사용됩니다. 이들은 독립적으로 개발되고 배포될 수 있으며, 기존 소스코드의 변경 없이 바꿔끼울 수 있는 구조를 갖게 됩니다.

마무리

객체지향 프로그래밍을 적극적으로 사용한다면 개발자들은 소프트웨어 시스템의 소스코드 의존성의 방향을 결정할 수 있는 권한을 얻을 수 있습니다. 이는 고수준 정책이 더 이상 저수준 정책에 의존하게 만들지 않고, 반대로 저수준 정책이 고수준 정책이 요구하는 바에 맞추어 개발하도록 구성됩니다. 이 과정에서 의존성 전이의 수준을 결정할 수 있으며, 상위 모듈이 요구하는 스펙만 맞추어 구현한다면 언제든 바꿔끼울 수 있는 유연함을 갖게 될 수 있습니다.

다음 글에서는 DIP를 실현하기 위한 방식 중 하나인 Dependency Injection에 대해 알아보겠습니다.