의존성 역전 원칙(Dependency Inversion Principle, DIP)

의존성 역전 원칙(Dependency Inversion Principle, DIP)

의존성 역전 원칙(Dependency Inversion Principle, DIP)은 추상화된 것은 구체적인 것에 의존해서는 안 된다는 원칙입니다. 이를 통해 시스템의 결합도를 낮추고 유연성과 확장성을 향상시킬 수 있습니다. 이해를 돕기 위해 간단한 예를 들어보겠습니다.

가정해봅시다. 우리는 온라인 쇼핑몰 시스템을 개발하고 있습니다. 이 시스템에는 주문(Order)을 처리하는 Order 클래스와 결제(Payment)을 담당하는 Payment 클래스가 있습니다. Order 클래스는 결제를 위해 Payment 클래스에 의존합니다.

처음에는 Order 클래스가 직접 Payment 클래스를 생성하고 사용할 수 있도록 코드를 작성할 수 있습니다. 예를 들어, 다음과 같은 형태일 수 있습니다:

public class Order {
    private Payment payment;

    public Order() {
        this.payment = new Payment();
    }

    public void processPayment() {
        payment.process();
    }
}

위의 코드에서 Order 클래스는 직접 Payment 클래스를 생성하고, Payment의 processPayment() 메서드를 호출합니다. 이러한 구조는 초기에는 동작할 수 있지만, 문제가 발생할 수 있습니다.

만약 나중에 다른 결제 시스템을 도입하거나 결제 방법을 추가하려고 할 때 문제가 발생합니다. 예를 들어, 신용카드 결제 외에도 은행 송금, 전자 지갑 등의 결제 수단을 추가하려면 Order 클래스의 코드를 변경해야 합니다. 이는 OCP(개방 폐쇄 원칙)에 위배될 수 있습니다.

이를 해결하기 위해 DIP를 적용해보겠습니다. 먼저, 추상화된 인터페이스를 도입하여 의존성을 역전시킵니다. Order 클래스는 Payment 인터페이스에만 의존하도록 변경합니다. 예를 들면 다음과 같습니다:

public class Order {
    private Payment payment;

    public Order(Payment payment) {
        this.payment = payment;
    }

    public void processPayment() {
        payment.process();
    }
}

이제 Order 클래스는 Payment 인터페이스에만 의존하므로, 구체적인 결제 방법에 대한 변경이 필요한 경우 Order 클래스의 코드를 수정할 필요가 없습니다. 대신, Payment 인터페이스를 구현하는 새로운 클래스를 만들어서 해당 클래스를 Order 객체 생성 시에 주입해주면 됩니다. 이를 통해 Order 클래스는 결제 시스템의 구체적인 구현과 분리되어 유연하고 확장 가능한 코드가 됩니다.

예를 들어, 신용카드 결제를 위한 CreditCardPayment 클래스와 은행 송금을 위한 BankTransferPayment 클래스를 만들고, 다음과 같이 Order 객체를 생성하면 됩니다:

Payment creditCardPayment = new CreditCardPayment();
Order order1 = new Order(creditCardPayment);

Payment bankTransferPayment = new BankTransferPayment();
Order order2 = new Order(bankTransferPayment);

이제 새로운 결제 수단을 추가하려면 단순히 새로운 Payment 구현체를 만들고 Order 객체를 생성할 때 주입해주기만 하면 됩니다. 이는 DIP를 따르는 객체 지향 설계의 예입니다.