[Clean Architecture] 12. SOLID 원칙 - DIP (Dependency Inversion Principle)

DIP

• 소스 코드 의존성이 추상에 의존하며 구현체에는 의존하지 않는 시스템
  • 이유: 의존한다는 것은 의존하는 대상이 변경될때 영향을 받으므로, '추상'은 '구체'보다 변화가 적기때문에 '추상'에 의존함으로서 변경에 유연한 코드를 유지하기 위함
  • 인터페이스는 구현체보다 변동성이 낮은 점을 사용
  • 소프트웨어 설계자는 인터페이스의 변동을 낮추고 구현체에 기능을 추가할 수 있는 방법을 찾기위해 노력
• 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 DIP를 무시
  
  • 예를 들어 자바의 String은 구체 클래스이며, String클래스가 변경되는 일이 거의 없으므로 DIP가 아니어도 안정적

Factory

• 아이디어: 변동성이 큰 구현체 객체를 생성할 때는 의존성을 주의하여 생성
• builder 역할
• 구현체 객체를 사용하기 위해서 또 다른 FactoryInterface의 메소드를 통해 구현체 객체를 얻어서 사용

ex) 

• Application에서는 Service Interface를 통해 Concreate Impl을 사용하지만, Application에서는 어떤 식으로든 ConcreteImpl의 인스턴스가 필요한 상황
• ConcreteImpl에 대해 소스 코드 의존성을 만들지 않으면서 할수 있는 방법은, Application이 ServiceFactory 인터페이스의 makeSvc 메서드 호출
• 그림에서의 곡선 의미: 구체적인 것들로부터 추상적인 것들을 분리
  • DIP: 해당 곡선과 교차할때 모두 한 방향으로 추상적인 쪽으로 향하는 형태 (제어 흐름과 소스코드 의존성이 반대 방향)

구체 컴포넌트

• DIP위배: 위 그림에서 구체 컴포넌트에는 구체적인 의존성이 하나 존재 (Service Factory Impl -> Concrete Impl)
• DIP를 위배를 모두 없애는것은 불가능
• 대다수의 시스템은 구체 컴포넌트를 최소한 하나는 포함
  • 보통 "main" 함수를 포함하는 Main 컴포넌트가 대표적
  • main함수는 ServiceFactoryImpl의 인스턴스를 생성한 후 이 인스턴스를 ServiceFaactory 타입으로 전역변수에 저장
  • Application은 이 전역 변수를 이용해서 Service FactoryImpl의 인스턴스에 접근

의존성 규칙 (Dependency Rule)

• 의존성은 추상적인 엔터티 쪽으로만 향하는 것