11장 DIP: 의존성 역전 원칙

11장 DIP: 의존성 역전 원칙

태그

비어 있음

날짜

2024년 4월 27일

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

이 아이디어는 확실히 비현실적이다.

소프트웨어 시스템이라면 구체적인 많은 장치에 의존하기 때문이다. String 클래스처럼 변경될 일이 거의 없다. 이처럼 변경될 일이 거의 없는 운영체제나 플랫폼 같은 안정적인 환경은 DIP를 논할 때 무시하는 편이다. 변경되지 않는다면 의존할 수 있다는 사실을 이미 알고 있기 때문이다. 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰 구체적인 요소다.

안정된 추상화

추상 인터페이스에 변경이 생기면 이의 구현체들도 수정해야 한다. 반대는 x

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

안정된 소프트웨어 아키텍처란 변동성이 큰 구현체에 의존하는 일은 지양하고, 안정된 추상 인터페이스를 선호하는 아키텍처이다.

변동성이 큰 구체 클래스를 참조하지 말라.

대신 추상 인터페이스를 참조하라.

변동성이 큰 구체 클래스로부터 파생하지 말라.

정적 타입 언어에서 상속은 소스 코드에 존재하는 모든 관계 중에서 가장 강력한 동시에 뻣뻣해서 변경하기 어렵다.

따라서 상속은 아주 신중하게 사용해야 한다.

구체 함수를 오버라이드 하지 말라.

대체로 구체 함수는 소스 코드 의존성을 필요로 한다. 따라서 구체 함수를 오버라이드 하면 이러한 의존성을 제거 할 수 없게 되며, 실제로는 그 의존성을 상속하게 된다.

이러한 의존성을 제거하려면, 차라리 추상 함수로 선언하고 구현체들에서 각자의 용도에 맞게 구현해야 한다.

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

이 실천법은 DIP 원칙을 다른 방식으로 풀어쓴 것이다.

팩토리

위 규칙들을 준수하려면 변동성이 큰 구체적인 객체는 특별히 주의해서 생성 해야 한다.

모든 언어에서 객체를 생성하려면 해당 “객체를 구체적으로 정의한 코드”에 대해 소스 코드 의존성이 발생하기 때문이다.

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

곡선은 아키텍처 경계를 뜻한다.

이 곡선은 구체적인 것들로부터 추상적인 것들을 분리한다.

소스 코드 의존성은 해당 곡선과 교차할 때 모두 한 방향, 즉 추상적인 쪽으로 향한다.

⇒ 소스 코드 의존성은 제어흐름과는 반대 방향으로 역전된다. 이러한 이유로 이 원칙을 의존성 역전이라고 부른다.

구체 컴포넌트

위의 그림에는 구체적인 의존성이 하나 있다.

ServiceFactoryImpl이 ConcreteImpl 을 의존한다.

일반적인 일이다. DIP위배를 모두 없앨 수는 없다.

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

결론

고수준의 아키텍처 원칙을 다루게 되면서 DIP는 자주 등장할 것이다. 그리고 DIP는 아키텍처 다이어그램에서 가장 눈에 드러나는 원칙이 될 것이다.

그림11.1(추상 팩토리)의 곡선은 이후의 장에서는 아키텍처 경계가 될 것이다.

그리고 의존성은 이 곡선을 경계로, 더 추상적인 엔티티가 있는 쪽으로만 향한다. 추후 이 규칙은 의존성 규칙이라 부를 것이다.

표