💾 [CS] 의존성 주입(DI, Dependency Injection).

1️⃣ 의존성 주입(DI, Dependency Injection)

• 싱글톤 패턴과 같이 사용하기 쉽고 굉장히 실용적이지만 모듈 간의 결합을 강하게 만들 수 있는 단점이 있는 패턴의 경우 의존성 주입(DI, Dependency Injection)을 통해 모듈 간의 결합을 조금 더 느슨하게 만들어 해결할 수 있습니다.
• 의존성이란 종속성이라고도 하며 A가 B에 의존성이 있다는 것은 B의 변경 사항에 대해 A 또한 변해야 된다는 것을 의미합니다.

• 앞의 그림처럼 메인 모듈(main module)이 ‘직접’ 다른 하위 모듈에 대한 의존성을 주기보다는 중간에 의존성 주입자(dependency injector)가 이 부분을 가로채 메인 모듈이 "간접적" 으로 의존성을 주입하는 방식입니다.
  • 이를 통해 메인 모듈(상위 모듈)은 하위 모듈에 대한 의존성이 떨어지게 됩니다.
    • 참고로 이를 ‘디커플링이 된다’ 고도 합니다.

1️⃣ 의존성 주입의 장점

• 모듈들을 쉽게 교체할 수 있는 구조가 되어 테스팅하기 쉽고 마이그레이션하기도 수월합니다.
  • 또한, 구현할 때 추상화 레이어를 넣고 이를 기반으로 구현체를 넣어 주기 때문에 애플리케이션 의존성 방향이 일관되고, 애플리케이션을 쉽게 추론할 수 있으며, 모듈 간의 관계들이 조금 더 명확해집니다.

2️⃣ 의존성 주입의 단점

• 모듈들이 더욱더 분리되므로 클래스 수가 늘어나 복잡성이 증가될 수 있으며 약간의 런타임 페널티가 생기기도 합니다.

3️⃣ 의존성 주입 원칙

• 의존성 주입은 "상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 합니다. 또한, 둘 다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 합니다." 라는 의존성 주입 원칙을 지켜주면서 만들어야 합니다.

위 문장에서 “추상화”의 의미.
문장에서 “추상화”는 구체적인 구현에 의존하지 않고, 일반화된 인터페이스나 추상 클래스 등에 의존해야 한다는 것을 뜻합니다.
이 원칙은 의존성 역전 원칙(DIP, Dependency Inversion Principle) 과 관련이 있습니다.

• 상위 모듈 : 애플리케이션의 상위 계층에서 동작하는 코드, 즉 더 높은 수준의 정책이나 로직을 구현하는 모듈입니다.
• 하위 모듈 : 상위 모듈에서 호출하거나 사용하는 구체적인 기능이나 세부 사항을 구현하는 코드입니다.

1️⃣ 추상화.

• “추상화” 는 객채 지향 프로그래밍(OOP)애서 중요한 개념 중 하나로, 구체적인 구현(details)을 감추고, 더 높은 수준의 개념을 정의하는 것을 의미합니다.
• 추상화는 구체적인 것보다는 더 일반적이고 보편적인 개념을 다루며, 특정한 구현 사항에 의존하지 않고 인터페이스나 추상 클래스 등을 통해 기능을 정의합니다.

2️⃣ 의존성 주입과 추상화의 관계.

• 의존성 주입(DI, Dependency Injection)은 의존성 역전 원칙(DIP, Dependency Inversion Principle)을 구현하기 위한 방법 중 하나입니다.
  • 의존성 주입을 사용하면, 상위 모듈이 하위 모듈의 구체적인 구현에 의존하지 않고, 하위 모듈이 구현한 추상화(인터페이스나 추상 클래스)에 의존하도록 코드를 설계할 수 있습니다.
    • 즉, 상위 모듈과 하위 모듈 모두 추상화된 인터페이스에 의존하게 하여, 구체적인 구현이 변경되더라도 상위 모듈의 코드가 영향을 받지 않도록 합니다.

3️⃣ 예시.

• 아래는 추상화와 의존성 주입을 적용한 예시입니다.

// 추상화된 인터페이스 (추상화)
public interface PaymentProcessor {
    void processPayment(double amount);
}

// 하위 모듈 - 구체적인 구현
public class PayPalProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        // PayPal을 통해 결제 처리
    }
}

public class CreditCardProcessor implements PaymentProcessor {
    @Override
    public void processPayment(double amount) {
        // 신용카드를 통해 결제 처리
    }
}

// 상위 모듈 - 추상화에 의존함
public class PaymentService {
    private PaymentProcessor paymentProcessor;
    
    // 의존성 주입을 통해 구현체를 주입 받음
    public PaymentService(PaymentProcessor paymentProcessor) {
        this.paymentProcessor = paymentProcessor;
    }
    
    public void makePayment(double amount) {
        paymentProcessor.processPayment(amount);
    }
}

• 위 코드에서 "PaymentService" 는 "PaymentProcessor" 라는 추상화에 의존합니다.
  • "PaymentService" 는 "PayPalProcessor" 나 "CreditCardProcessor" 의 구체적인 구현을 알 필요가 없으며, 단지 "PaymentProcessor" 인터페이스에 정의된 메서드를 호출합니다.
    - 이를 통해 결제 처리 방식이 PayPal에서 신용카드로 변경되더라도 "PaymentService" 는 수정할 필요가 없습나다.

이처럼 “추상화”는 상위 모듈과 하위 모듈이 특정 구현이 아닌, 일반적인 개념에 의존하도록 만들어줌으로써, 코드의 유연성과 재사용성을 높여주는 중요한 개념입니다.