[디자인 패턴] - Strategy

Strategy

알고리즘(전략)들을 캡슐화해서, 서로 교환 가능하게 만들고, 런타임에도 전략을 쉽게 변경할 수 있도록 설계하는 패턴이다.

즉, 어떤 기능을 수행하는 여러 방식(전략)이 있고, 이 전략들을 인터페이스로 분리해서 필요할 때 교체하거나 확장할 수 있게 해준다.

 

예시 코드

// 전략 인터페이스
interface PaymentStrategy {
    void pay(int amount);
}

// 구체적인 전략들
class CreditCardPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("신용카드로 " + amount + "원 결제했습니다.");
    }
}

class KakaoPayPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("카카오페이로 " + amount + "원 결제했습니다.");
    }
}

// Context 클래스
class ShoppingCart {
    private PaymentStrategy paymentStrategy;

    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.paymentStrategy = strategy;
    }

    public void checkout(int amount) {
        paymentStrategy.pay(amount);
    }
}

// 사용 예시
public class StrategyPatternExample {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();

        cart.setPaymentStrategy(new CreditCardPayment());
        cart.checkout(10000); // 신용카드 결제

        cart.setPaymentStrategy(new KakaoPayPayment());
        cart.checkout(20000); // 카카오페이 결제
    }
}

 

Strategy 패턴의 장점

전략 교체가 용이

런타임 중에도 전략 객체를 바꿔 끼울 수 있다.

 

유지보수성 향상

알고리즘을 개별 클래스로 분리해서 관리하므로 코드 수정이 쉽다.

 

OCP (개방-폐쇄 원칙)

새로운 전략을 추가할 때 기존 코드를 변경하지 않아도 된다.

 

코드 중복 제거

다양한 알고리즘을 공통 인터페이스로 통일 가능하다.

 

Strategy 패턴의 단점

클래스 수 증가

전략이 많아질수록 클래스가 많아진다.

 

클라이언트가 전략을 알아야 함

어떤 전략이 있는지 클라이언트가 선택해야 하는 책임이 있다.

 

불필요한 추상화 가능성

단순한 경우에는 오히려 복잡도를 증가시킬 수 있다.

 

Strategy 패턴은 언제 사용하나?

동일한 기능을 다양한 방식으로 수행해야 할 때

ex) 정렬(버블/퀵/머지), 결제 방식(카드/페이/계좌이체)

 

조건문(if/switch)으로 알고리즘을 선택하는 경우

전략 클래스로 분리해서 깔끔하게 대체 가능

 

전략을 런타임에 교체하고 싶을 때

실행 중에 전략을 선택할 수 있게 해야 하는 경우

 

정리하자면

알고리즘을 독립적으로 캡슐화하여, 서로 교체 가능하게 만들고 클라이언트 코드에서 유연하게 전략을 선택하도록 해주는 패턴이다.