답변.

**의존 역전 원칙(Dependency Inversion Principle, DIP)**은 다음과 같은 아키텍처 원칙입니다:

고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 두 가지 모두 추상화(인터페이스)에 의존해야 합니다.
추상화는 세부사항에 의존해서는 안 되며, 세부사항은 추상화에 의존해야 합니다.

즉, 비즈니스 로직(예: 주문 처리 서비스)은 특정 인프라 구현(예: 이메일 발송을 구현하는 클래스)을 직접 사용하거나 알 필요가 없으며, DI 컨테이너나 수동으로 주입되는 추상화(인터페이스)를 통해 작업해야 합니다.

C# 코드 예시:

public interface IEmailSender {
    void Send(string to, string message);
}

public class SmtpEmailSender : IEmailSender {
    public void Send(string to, string message) {
        // 이메일 전송 구현
    }
}

public class OrderService {
    private readonly IEmailSender _emailSender;

    public OrderService(IEmailSender emailSender) {
        _emailSender = emailSender;
    }
    public void PlaceOrder(string customer) {
        // 비즈니스 로직
        _emailSender.Send(customer, "주문이 접수되었습니다!");
    }
}

주요 특징:

구현 세부사항을 쉽게 교체할 수 있게 해줍니다(예: 테스트에서 목 객체를 주입할 수 있음).
아키텍처의 테스트 용이성과 확장성을 높입니다.
모듈 간의 느슨한 결합을 보장합니다.

함정 질문.

DIP는 단지 생성자를 통한 의존성 주입입니까?

아니요. DIP는 추상화를 구현으로부터 분리하는 것입니다. 의존성 주입(Dependency Injection, DI)은 DIP를 구현하는 데에 사용하는 도구일 뿐입니다. DIP는 DI 컨테이너 없이 수동으로 추상화와 세부사항을 구분하여 구현할 수 있습니다.

인터페이스의 구현이 하나뿐이라면 DIP가 반드시 필요합니까?

네, 확장이 가능하다면 원칙은 여전히 적용됩니다. 추상화를 도입하면 고수준 코드의 수정 없이 요구 사항 변경에 대비할 수 있습니다. 인터페이스의 구현이 하나라도 느슨한 결합은 시스템의 테스트와 발전을 용이하게 합니다.

팩토리나 서비스 로케이터에서 로직을 사용하면 DIP를 위반할 수 있습니까?

예. 팩토리나 서비스 로케이터가 구현 세부사항을 알고 클라이언트 측에서 인터페이스를 사용하지 않고 동적으로 연결하면 DIP는 위반됩니다, 비록 외부에 추상화가 존재하더라도 말입니다.

의존 역전 원칙(Dependency Inversion Principle)은 아키텍처 설계에서 무엇을 의미하며, 코드에서 단순 의존 역전과는 어떻게 다릅니까?

답변.

함정 질문.