출처
클린 아키텍처를 읽으며 정리한 내용입니다.
11. DIP: 의존성 역전 원칙
DIP에서 말하는 유연성이 극대화된 시스템이란, 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템이다.
즉, 자바같은 정적 타입 언어에서 use, import, include 구문은 오직 인터페이스나 추상 클래스같은 추상적인 선언만을 참조해야 한다는 뜻이다.
동적 타입 언어에도 동일한 규칙이 적용되지만, 이 언어의 경우 구체 모듈이 무엇인지 정의하기가 어려우며 호출할 함수가 구현된 모듈이라면 참조하지 않기 어렵다. DIP는 규칙으로 무조건 지키기엔 비현실적이다. 실제로 소프트웨어 시스템이라면 구체적인 장치에 반드시 의존하게 되어있다.
자바에서도 String은 구체 클래스이고, 아무도 이것을 추상 클래스로 만들려고 하지 않는다. 이는 String 클래스가 매우 안정적이기 때문에 가능한 일이다.
그래서 DIP는 운영체제나 플랫폼 등 안정성이 보장된 환경에서는 논하지 않는다. 변경되지 않는다면 의존할 수 있다. 우리가 의존하지 않아야 하는 것은 열심히 개발중인, 변동성이 큰 구체적인 요소다.
안정된 추상화
안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처라는 뜻이다.
이 원칙을 지키기 위한 코딩 실천법은 다음과 같다.
- 정적 타입 언어든 동적 타입 언어든 변동성이 큰 구체 클래스를 참조하지 말고, 대신 추상 인터페이스를 참조하라.
- 변동성이 큰 구체 클래스로부터 파생하지 말라. 정적 타입 언어에서 상속은 가장 강력하고 뻣뻣한 관계이며, 변경하기 어렵다. 동적 타입 언어에서도 의존성을 가지도록 한다.
- 구체 함수를 오버라이드 하지 말라. 대체로 구체 함수는 소스 코드 의존성을 필요로 하는데, 구체 함수를 오버라이드 하면 이 의존성을 제거할 수 없게 되며 상속하게 된다.
- 차라리 추상 함수로 선언하고 구현체에서 각 용도에 맞게 구현해라.
- 구체적이며 변동성이 크다면 절대 그 이름을 언급하지 마라.
팩토리
이 규칙들을 준수하기 위해서는 변동성이 큰 구체적 객체를 주의해서 생성해야 한다. 대부분의 객체 지향 언어에서는 이런 바람직하지 못한 의존성을 처리하기 위해 추상 팩토리를 사용하곤 한다.
- 추상 팩토리 구조 예시
- Application은 Service 인터페이스를 통해 ConcreteImpl을 사용하지만, 어떻게든 ConcreteImpl의 인스턴스를 생성해야 하긴 한다.
- ConcreteImpl에 대해 의존성을 만들지 않으면서 인스턴스를 생성하기 위해 ServiceFactory 인터페이스의 makeSvc 메서드를 호출한다.
- 이 메서드는 ServiceFactory로부터 파생된 ServiceFactoryImpl에서 구현된다.
- ServiceFactoryImpl 구현체가 ConcreteImpl의 인스턴스 생성 후 Service 타입으로 반환한다.
- 여기에서의 곡선은 구체적인 것과 추상적인 것을 분리하고, 소스 코드 의존성은 모두 이 곡선과 교차할 때 추상적인 쪽으로 향한다.
- 추상 컴포넌트는 애플리케이션의 고수준 업무 규칙을 포함하며, 구체 컴포넌트는 업무 규칙을 위해 필요한 세부사항을 포함한다.
- 제어흐름은 소스 코드 의존성과 반대 방향으로 곡선을 가로지른다. → 의존성 역전
구체 컴포넌트
위 예시의 구체 컴포넌트에도 구체적인 의존성이 하나 있듯이 DIP 위배를 모두 없앨 수는 없다. 하지만 DIP를 위배하는 클래스를 적은 수의 구체 컴포넌트 내부로 모아 시스템의 나머지 부분과 분리할 수 있다.
이러한 구체 컴포넌트를 흔히 메인이라고 부르는데, 메인 함수를 포함하기 때문이다.
결론
DIP는 아키텍처 다이어그램에서 가장 눈에 띄며, 위 예시의 곡선은 이후의 장에서 아키텍처 경계로 나타날 것이다.
이 곡선을 경계로 의존성이 더 추상적인 엔티티가 있는 쪽으로만 향하는 것을 의존성 규칙이라 부르게 될 것이다.
