종속성 반전 원리

상위 모듈은 하위 모듈에 의존해서는 안 됩니다. 둘 다 추상화에 의존해야 합니다.

추상화는 세부 사항에 의존해서는 안 되며, 세부 사항은 추상화에 의존해야 합니다.

예를 통해 상위 모듈과 하위 모듈을 이해해 보겠습니다.

Flipkart와 같은 높은 수준의 전자상거래 앱에서는 ProductCatalog, PaymentProcessor 및 CustomerProfile로 분류될 수 있습니다(이들은 주요 비즈니스 기능 중 일부입니다)
이러한 비즈니스 기능은 위 이미지에 표시된 다른 모듈과 상호 의존합니다.

참고: 상단의 모듈은 상위레벨 모듈
이라는 비즈니스 기능에 더 가깝습니다. 하단의 모듈은 하위레벨 모듈

이라는 구현 세부 사항에 가깝습니다.

하위 수준 모듈은 SQLProductRepository, GooglePayService, WireTransfer, EmailSender 및 VoiceDialer입니다.

CustomerProfile(상위 모듈)과 Communication 모듈만 고려하면 Communication은 Low-level 모듈이지만 Communication, EmailSender 및 VoiceDialer만 고려하면 Communication은 High-level 모듈이 되고 EmailSender 및 VoiceDialer는 저수준 모듈입니다.

여기서 중요한 점은 상위모듈과 하위모듈의 개념이 절대적인 것이 아니라 상대적인이라는 개념입니다.

위의 이미지에 따르면 ProductCatalog는 SQLProductRepository에 따라 다릅니다. 즉, 상위 수준 모듈이 하위 수준 모듈에 종속되지만 이는 DIP의 첫 번째 정의와 직접적으로 충돌합니다

.

---

ProductCatalog → SQLProductRepository 관계를 살펴보고 더 분석해 보겠습니다.

import java.util.List;
/*
 * High-Level module
*/
public class ProductCatalog {
    public void listAllProducts(){
        SQLProductRepository sqlProductRepository = new SQLProductRepository();
        List<string> allProductsNames = sqlProductRepository.getAllProductNames();
        //Display all products names
    }
}
</string>

/*
 * Low-level module 
*/
import java.util.Arrays;
import java.util.List;
public class SQLProductRepository {
    public List<string> getAllProductNames(){
        return Arrays.asList("soap","toothpaste");
    }
}
</string>

ProductCatalog는 SQLProductRepository에 직접적으로 의존하므로 이는 분명히 DIP 정의 1을 위반하는 것입니다(정의에 따르면 고수준 모듈과 저수준 모듈은 모두 추상화에 의존해야 합니다

)

이 문제를 정의 1에 따라 수정하겠습니다.

인터페이스 ProductRepository 생성

import java.util.List;

public interface ProductRepository {
    public List<string> getAllProductNames();
}
</string>

SQLProductRepository에서 이 인터페이스 구현

/*
 * Low-level module 
*/
import java.util.Arrays;
import java.util.List;
public class SQLProductRepository  implements ProductRepository{
    @Override
    public List<string> getAllProductNames(){
        return Arrays.asList("soap","toothpaste");
    }
}
</string>

마지막으로 상위 수준 모듈 ProductCatalog의 경우 SQLProductRepository를 직접 인스턴스화해서는 안 됩니다
. 동일한 작업을 위해 ProductFactory 클래스를 사용하겠습니다

public class ProductFactory {
    public static ProductRepository create(){
        return new SQLProductRepository();
    }
}

ProductFactory를 사용하여 SQLProductRepository를 인스턴스화합니다

/*
 * High-Level module
*/
import java.util.List;

public class ProductCatalog {
    public void listAllProducts(){
        ProductRepository productRepository = ProductFactory.create();
        List<string> allProductsNames = productRepository.getAllProductNames();
        //Display all products names
    }
}
</string>

참조 개체는 ProductRepository이므로 SQLProductRepository와 긴밀한 결합이 없습니다.

수정 후 새 종속성은 다음과 같습니다

위 변경 사항은 DIP 정의 1에 따릅니다.
위의 코드 변경은 DIP의 두 번째 정의도 따릅니다. 즉, 추상화는 세부 사항에 의존해서는 안 되고, 세부 사항은 추상화에 의존해야 합니다. 위의 이미지에서 볼 수 있듯이 SQLProductRepository는 그 반대가 아니라 ProductRepository에 의존합니다. 이 원리를 의존성 역전의 원리라고 부르는 이유는

---

의존성 주입과 의존성 반전

Even though they are related, they are not the same and can not be used interchangeably 

의존성 주입 이해:

ProductCatalog에서는 팩토리 메서드 ProductFactory.create()를 사용하여 SQLProductRepository 개체의 인스턴스를 가져옵니다.
인스턴스 생성 프로세스를 팩토리 클래스 ProductFactory에 위임하지만 초기화 프로세스는 여전히 ProductCatalog 클래스를 사용합니다.
이상적으로는 ProductCatelog 클래스가 인스턴스화를 트리거하는 방법과 시기를 걱정하는 것을 원하지 않습니다.

요청하지 않고도 인스턴스화된 ProductRepository 클래스를 ProductCatalog에 제공하면 어떻게 될까요?

그래서 Main 클래스 ECommerceMainApplication은 팩토리 메소드 ProductFactory.create()를 사용하여 ProductRepository의 인스턴스를 생성하고 이 인스턴스는 ProductRepositroy 클래스 생성자의 인수로 전달됩니다.

public class ECommerceMainApplication {
    public static void main(String agrs[]) {
        ProductRepository productRepository = ProductFactory.create();
        ProductCatalog productCatalog = new ProductCatalog(productRepository);
        productCatalog.listAllProducts();
    }
}

ProductCatalog 클래스를 적절하게 업데이트한 후

import java.util.List;

public class ProductCatalog {

    private ProductRepository productRepository;

    public ProductCatalog(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    public void listAllProducts(){
        List<string> allProductsNames = productRepository.getAllProductNames();
        //Display all products names
        allProductsNames.forEach(product-> System.out.println(product));
    }
}
</string>

이제 ProductCatalog는 언제 어디서든 SQLProductRepository 개체를 자유롭게 사용할 수 있습니다. 더 이상 SQLProductRepository 개체를 자체적으로 생성하는 것에 대해 걱정할 필요가 없습니다. 즉, 종속성 인스턴스화에 대해 걱정하는 ProductCatalog 대신 우리는 종속성을 ProductCatalog에 주입
합니다. 이것이 의존성 주입

---

의 개념입니다.

제어 반전 - IOC

DIP(Dependency Inversion 원리)의 일부는 아니지만 밀접하게 연관되어 있습니다

위와 같은 코드로 이해해보자

ProductCatalog 클래스에는 ProductRepository 개체를 사용하는 생성자가 있습니다.

ProductCatalog를 호출하는 클래스는 ProductRepository의 개체를 제공하거나 주입합니다. 이 경우 ECommerceMainApplication입니다.
ProductCatalog 클래스 외부에서 주입이 발생하더라도 주입은 여전히 ​​프로그램의 기본 흐름 중에 발생합니다. 즉, 프로그램 실행의 메인 스레드에서 주입이 발생합니다.

주 제어 흐름이 주입과 완전히 분리되도록 모든 주입이 별도의 스레드나 별도의 컨텍스트에서 모두 발생하도록 하려면 어떻게 해야 할까요?

이는 Spring(Java)과 같은 프레임워크를 사용하여 달성할 수 있습니다.

Spring은 프로그램의 주요 흐름과 다른 맥락을 실행합니다
Spring은 클래스의 필수 종속성을 주입하는 작업을 처리합니다. 따라서 클래스 객체를 인스턴스화하려면 코드에서 직접 수행하는 대신 Spring에 클래스 객체를 제공하도록 요청하세요.
Spring 프레임워크는 객체 인스턴스화에 필요한 모든 종속성을 살펴본 다음 모든 종속성을 주입하고 객체를 인스턴스화한 후 이를 기본 제어 흐름에 다시 제공합니다.
따라서 종속성 주입에 대한 제어는 Spring 프레임워크에 완전히 위임되며 메일 제어 흐름에서는 발생하지 않습니다.
이 개념을 IOC(Inversion of Control)라고 하며 Spring을 Inversion of Control Container 또는 간단히 IOC 컨테이너

라고 합니다.

위 내용은 종속성 반전 원리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!