[oop] 의존성 역전 원리는 무엇이며 왜 중요한가?

C #의 민첩한 소프트웨어 개발, 원칙, 패턴 및 사례와 민첩한 원칙, 패턴 및 사례는 Dependency Inversion Principle의 원래 목표와 동기를 완전히 이해하는 데 가장 적합한 리소스입니다. “The Dependency Inversion Principle”이라는 기사도 좋은 자료이지만, 이전에 언급 된 책으로 들어가는 초안의 요약 버전이라는 사실 때문에 이 원칙을보다 일반적인 조언과 구별하기위한 핵심 인 패키지 및 인터페이스 소유권은 Design Patterns (Gamma, et al.) 책에서 찾을 수있는 “구현이 아닌 인터페이스로의 프로그래밍”에 대한 조언입니다.

요약을 제공하기 위해 Dependency Inversion Principle은 주로 “상위 레벨”구성 요소가 “상위 레벨”구성 요소가 소유 한 인터페이스에 종속되도록 “상위 레벨”구성 요소에서 “하위 레벨”구성 요소로의 기존 종속성 방향을 반전시키는 것에 관한 것 입니다. . (참고 : 여기서 “높은 수준”구성 요소는 계층 구조 내에서 개념적 위치 일 필요는 없지만 외부 종속성 / 서비스가 필요한 구성 요소를 나타냅니다. 그렇게하면 이론적으로 구성 요소에서 이동 하는 것처럼 커플 링이 크게 줄어들지 는 않습니다. 이론적으로 더 가치가있는 구성 요소에는 덜 가치가 있습니다.

이것은 외부 의존성이 컴포넌트의 소비자에 의해 구현이 제공되어야하는 인터페이스의 관점에서 표현되는 컴포넌트를 설계함으로써 달성된다. 다시 말해, 정의 된 인터페이스는 컴포넌트 사용 방법이 아니라 컴포넌트에 필요한 것을 표현합니다 (예 : “IDoSomething”이 아닌 “INeedSomething”).

Dependency Inversion Principle에서 언급하지 않는 것은 인터페이스를 사용하여 종속성을 추상화하는 간단한 방법입니다 (예 : MyService → [ILogger ⇐ Logger]). 이렇게하면 종속성의 특정 구현 세부 사항에서 구성 요소가 분리되지만 소비자와 종속성 간의 관계는 반전되지 않습니다 (예 : [MyService → IMyServiceLogger] ⇐ Logger).

Dependency Inversion Principle의 중요성은 기능의 일부 (로깅, 유효성 검사 등)에 외부 종속성에 의존하는 소프트웨어 구성 요소를 재사용 할 수 있다는 단일 목표로 나눌 수 있습니다.

이 일반적인 재사용 목표 내에서 두 가지 하위 유형의 재사용을 설명 할 수 있습니다.

1. 하위 종속성 구현으로 여러 응용 프로그램 내에서 소프트웨어 구성 요소 사용 (예 : DI 컨테이너를 개발하고 로깅을 제공하려고하지만 컨테이너를 사용하는 모든 사람이 특정 로거에 컨테이너를 연결하지는 않음) 선택한 로깅 라이브러리를 사용하십시오).

2. 진화하는 상황에서 소프트웨어 구성 요소 사용 (예 : 구현 세부 사항이 발전하는 여러 버전의 응용 프로그램에서 동일하게 유지되는 비즈니스 논리 구성 요소를 개발했습니다).

인프라 라이브러리와 같이 여러 응용 프로그램에서 구성 요소를 재사용하는 첫 번째 경우 목표는 이러한 종속성에 의존하기 위해서는 소비자가 자신의 라이브러리의 하위 종속성에 연결하지 않고 소비자에게 핵심 인프라를 제공하는 것입니다. 소비자들도 같은 의존성을 요구해야합니다. 라이브러리 소비자가 동일한 인프라 요구 사항 (예 : NLog와 log4net)에 대해 다른 라이브러리를 사용하기로 선택하거나 이전 버전과 호환되지 않는 필수 라이브러리의 이후 버전을 사용하기로 선택한 경우 문제가 될 수 있습니다. 도서관에서 필요합니다.

비즈니스 논리 구성 요소 (예 : “상위 레벨 구성 요소”)를 재사용하는 두 번째 경우의 목표는 응용 프로그램의 핵심 도메인 구현을 구현 세부 사항의 변경 요구 (예 : 지속성 라이브러리, 메시징 라이브러리 변경 / 업그레이드)에서 분리하는 것입니다. , 암호화 전략 등). 이상적으로 응용 프로그램의 구현 세부 사항을 변경해도 응용 프로그램의 비즈니스 논리를 캡슐화하는 구성 요소가 손상되지 않아야합니다.

참고 : 일부는이 두 번째 사례를 실제 재사용으로 설명하는 데 반대 할 수 있습니다. 단일 진화하는 응용 프로그램 내에서 사용되는 비즈니스 논리 구성 요소와 같은 구성 요소는 단일 용도 일뿐입니다. 그러나 여기서 아이디어는 응용 프로그램의 구현 세부 사항을 변경할 때마다 새로운 컨텍스트와 다른 사용 사례를 렌더링하지만 궁극적 목표는 격리와 이식성으로 구분 될 수 있다는 것입니다.

이 두 번째 사례에서 Dependency Inversion Principle을 따르는 것이 약간의 이점을 제공 할 수 있지만 Java 및 C #과 같은 현대 언어에 적용되는 가치는 크게 관련이없는 수준으로 줄어든다는 점에 유의해야합니다. 앞에서 설명한 것처럼 DIP는 구현 세부 정보를 별도의 패키지로 완전히 분리합니다. 그러나 진화하는 애플리케이션의 경우, 비즈니스 도메인 측면에서 정의 된 인터페이스를 사용하면 구현 세부 사항 구성 요소의 변경 요구로 인해 더 높은 레벨의 구성 요소를 수정해야 할 필요가 없습니다. . 이 원칙의이 부분은 새로운 언어와 관련이없는 원칙이 체계화 될 때 (즉, C ++) 해당 언어와 관련된 측면을 반영합니다. 그것은 말했다

인터페이스의 간단한 사용, 종속성 주입 및 분리 된 인터페이스 패턴과 관련된이 원칙에 대한 자세한 설명은 여기를 참조하십시오 . 또한이 원칙이 JavaScript와 같은 동적 유형 언어와 어떤 관련이 있는지에 대한 설명은 여기를 참조하십시오 .

답변

// DataAccessLayer.dll
public class ProductDAO {

}

// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
    private ProductDAO productDAO;
}

// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{

}

// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
    private IProductDAO productDAO;
}

// Domain.dll
public interface IProductRepository;

using DataAccessLayer;
public class ProductBO {
    private IProductRepository productRepository;
}

// Persistence.dll
public class ProductDAO : IProductRepository{

}