Strategy (스트래티지) - 행위 패턴 #2

목차

💡

• 왜 스트래티지 패턴을 사용해야 하는가?
• 설계도는 어떻게 생겼나?
• 실제로 어떻게 구현하나?
• 장점과 단점은 무엇인가?

왜 스트래티지 패턴을 사용해야 하는가?

런타임 중에 전략을 갈아 바꿔야할 때가 있습니다.

각각의 기능들을 캡슐화해서 큰 변경 없이, 단순히 객체만 갈이 끼우는 식으로 해서 , 전략적으로 사용할 수 있게 됩니다.

예를 들어, 쇼핑몰 결제를 해야할 때, 신용카드든 카카오페이든 네이버페이든 모종의 수단으로 결제를 한다는 것은 동일합니다.

그러므로 결제를 한다라는 행위만 지정하고, 그 내부는 인터페이스를 상속 받은 무언가로 구현하면 됩니다.

설계도는 어떻게 생겼나?

먼저 인터페이스를 활용해 각각의 결제 기능을 독립적인 객체로 만듭니다. 그리고 결제를 진행하는 본체인 컨텍스트는 구체적인 방식 대신 이 인터페이스만 바라보고 작동하게 합니다.

이렇게 구현해 두면 실제 사용자 입장에서는 전체 코드를 뜯어고칠 필요가 없습니다. 그저 상황에 맞춰 신용카드나 카카오페이 객체로 교체만 해주면 결제 방식이 유연하게 바뀝니다.

실제로 어떻게 구현하나?

인터페이스 및 구현체

// 1. 전략 인터페이스 (공통된 행동 정의)
public interface PaymentStrategy {
    void pay(int amount);
}

// 2. 구체적인 전략 구현 (신용카드 결제)
public class CreditCardStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("💳 " + amount + "원을 신용카드로 결제합니다.");
    }
}

// 3. 구체적인 전략 구현 (카카오페이 결제)
public class KakaoPayStrategy implements PaymentStrategy {
    @Override
    public void pay(int amount) {
        System.out.println("🟡 " + amount + "원을 카카오페이로 결제합니다.");
    }
}

컨텍스트

// 전략을 사용하는 장바구니 클래스
public class ShoppingCart {
    private PaymentStrategy paymentStrategy;

    // 실행 중에 전략을 변경할 수 있도록 세팅(주입) 메서드 제공
    public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
        this.paymentStrategy = paymentStrategy;
    }

    // 구체적인 결제 방식은 모르지만, 인터페이스를 통해 결제 실행
    public void checkout(int amount) {
        if (paymentStrategy == null) {
            System.out.println("결제 수단이 선택되지 않았습니다.");
            return;
        }
        paymentStrategy.pay(amount);
    }
}

사용 예시

public class Main {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();

        // 1. 신용카드로 결제 전략 설정
        cart.setPaymentStrategy(new CreditCardStrategy());
        cart.checkout(10000);

        // 2. 실행 중(런타임)에 카카오페이로 결제 전략 변경
        cart.setPaymentStrategy(new KakaoPayStrategy());
        cart.checkout(20000);
    }
}

장점과 단점은 무엇인가?

장점

• 유연성과 확장성 준수 or OCP 준수
  • 새로운 기능을 도입할 때, 기존 코드를 수정할 필요 없이, 새로운 클래스만 추가하면 됩니다.
• 조건문 감소
  • 복잡한 if-else나 switch문을 제거하므로 코드가 훨씬 깔끔해 집니다.

단점

• 구현할 클래스 증가
  • 각각의 전략마다 새로운 클래스를 만들어야 하므로, 클래스의 수가 필연적으로 많아지게 됩니다.
• 구현의 부담
  • 개발하는 사람이 적절한 전략을 객체 생성해야하므로, 전체적인 흐름을 대략적으로 알고 있어야 합니다.