[책 정리] 11장. DIP(Dependency Inversion Principle) : 의존성 역전 원칙 - Clean Architecture

-

의존성 역전 원칙(DIP)에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concrete)에는 의존하지 않는 시스템이다.

자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다.

구체적인 대상에는 절대로 의존해서는 안 된다.

DIP 를 논할 때 운영체제나 플랫폼 같이 안전성이 보장된 환경에 대해서는 이를 무시하는 편이다.

이들 환경에 대한 의존성은 용납하는데, 변경되지 않는다면 의존할 수 있다는 사실을 이미 알고 있기 때문이다.

-

우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰(volatile) 구체적인 요소다.

그리고 이 구체적인 요소는 우리가 열심히 개발하는 중이라 자주 변경될 수밖에 없는 모듈들이다.

안정된 추상화

-

추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다.

반대로 구체적인 구현체에 변경이 생기더라도 그 구현체가 구현하는 인터페이스는 항상, 좀 더 정확히 말하면 대다수의 경우 변경될 필요가 없다.

따라서 인터페이스는 구현체보다 변동성이 낮다.

-

실제로 뛰어난 소프트웨어 설계자와 아키텍트라면 인터페이스의 변동성을 낮추기 위해 애쓴다.

인터페이스를 변경하지 않고도 구현체에 기능을 추가할 수 있는 방법을 찾기 위해 노력한다.

이는 소프트웨어 설계의 기본이다.

-

변동성이 큰 구체 클래스를 참조하지 말라. 대신 추상 인터페이스를 참조하라.

변동성이 큰 구체 클래스로부터 파생하지 말라. 상속은 아주 신중하게 사용해야 한다. 

구체 함수를 오버라이드 하지 말라. 차라리 추상 함수로 선언하고 구현체들에서 각자의 용도에 맞게 구현해야 한다.

구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 말라.

팩토리

-

자바 등 대다수의 객체 지향 언어에서 바람직하지 못한 의존성을 처리할 때 추상 팩토리를 사용하곤 한다.

구체 컴포넌트

-

DIP 위배를 모두 없앨 수는 없다.

하지만 DIP 를 위배하는 클래스들은 적은 수의 구체 컴포넌트 내부로 모을 수 있고, 이를 통해 시스템의 나머지 부분과는 분리 할 수 있다.

대다수의 시스템은 이러한 구체 컴포넌트를 최소한 하나는 포함할 것이다.

흔히 이 컴포넌트를 메인(main)이라고 부르는데, main 함수를 포함하기 때문이다.

결론

-

의존성은 더 추상적인 엔티티가 있는 쪽으로만 향한다.

이를 의존성 규칙(Dependency Rule)이라 부른다.