[디자인 패턴] 행위 패턴 - Strategy Pattern (전략 패턴)

목차

 

 

📇 개요

전략 패턴(Strategy Pattern)은 알고리즘을 캡슐화하여 실행 중에 알고리즘을 선택하고 교체할 수 있게 하는 디자인 패턴이다. 즉, 같은 문제를 해결하는 여러 알고리즘을 별도의 클래스로 분리하고, 이들을 인터페이스를 통해 교체 가능하게 만드는 방식이다.

 

특징

• 행위(알고리즘)를 클래스로 캡슐화하여 동적으로 교체할 수 있다.
• 컨텍스트(Context)와 전략(Strategy)을 분리하여 결합도를 낮춘다.
• OCP(개방-폐쇄 원칙)를 준수하며 새로운 전략을 쉽게 추가할 수 있다.

 

👩🏻‍💻 코드로 알아보자

다양한 결제 방식을 구현하는 전략 패턴 예제를 살펴보자.

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

// 2. 구체적인 전략 클래스들
class CreditCardPayment implements PaymentStrategy {
    private String cardNumber;
    private String name;

    public CreditCardPayment(String cardNumber, String name) {
        this.cardNumber = cardNumber;
        this.name = name;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + "원을 신용카드(" + cardNumber + ")로 결제했습니다.");
    }
}

class NaverPayPayment implements PaymentStrategy {
    private String email;

    public NaverPayPayment(String email) {
        this.email = email;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + "원을 네이버페이(" + email + ")로 결제했습니다.");
    }
}

class BankTransferPayment implements PaymentStrategy {
    private String bankAccount;

    public BankTransferPayment(String bankAccount) {
        this.bankAccount = bankAccount;
    }

    @Override
    public void pay(int amount) {
        System.out.println(amount + "원을 계좌이체(" + bankAccount + ")로 결제했습니다.");
    }
}

// 3. 컨텍스트 클래스
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 StrategyPatternExample {
    public static void main(String[] args) {
        ShoppingCart cart = new ShoppingCart();

        // 신용카드 결제
        System.out.println("💳 신용카드 결제");
        cart.setPaymentStrategy(new CreditCardPayment("1234-5678-9012-3456", "홍길동"));
        cart.checkout(80000);

        // 네이버페이 결제
        System.out.println("\n🟢 네이버페이 결제");
        cart.setPaymentStrategy(new NaverPayPayment("user@example.com"));
        cart.checkout(50000);

        // 계좌이체 결제
        System.out.println("\n🏦 계좌이체 결제");
        cart.setPaymentStrategy(new BankTransferPayment("123-456-789"));
        cart.checkout(100000);
    }
}

• PaymentStrategy 인터페이스가 모든 결제 전략의 공통 인터페이스 역할을 한다.
• 구체적인 전략 클래스들(CreditCardPayment, NaverPayPayment, BankTransferPayment)이 각각의 결제 알고리즘을 구현한다.
• ShoppingCart는 컨텍스트 클래스로, 설정된 전략을 사용하여 결제를 처리한다.
• 실행 중에 다양한 결제 방식으로 교체 가능하다.

 

 

 

☘️ 장/단점

✅ 장점

1. 알고리즘 교체 용이성
   • 실행 중에 알고리즘을 교체할 수 있어 유연성이 높다.
   • 사용자 요구에 따라 다른 전략으로 쉽게 전환할 수 있다.
2. 코드 재사용 및 중복 제거
   • 각 전략은 독립적으로 구현되어 알고리즘 코드를 재사용할 수 있다.
   • 유사한 기능을 여러 클래스에서 중복 구현할 필요가 없다.
3. 컨텍스트와 알고리즘 분리
   • 컨텍스트(ShoppingCart)는 구체적인 알고리즘을 몰라도 되므로 결합도가 낮아진다.
   • 이는 코드 유지보수성과 테스트 용이성을 높인다.
4. 새로운 전략 추가 용이
   • 기존 코드를 변경하지 않고 새로운 전략을 추가할 수 있다(OCP 준수).
   • 예를 들어, KakaoPayPayment 같은 새로운 결제 방식을 쉽게 추가할 수 있다.

 

❌ 단점

1. 클래스 수 증가
   • 각 알고리즘마다 별도의 클래스가 필요하므로 전체 클래스 수가 많아질 수 있다.
   • 작은 프로젝트에서는 오히려 복잡성을 증가시킬 수 있다.
2. 클라이언트가 전략을 알아야 함
   • 클라이언트가 적절한 전략을 선택하고 설정해야 하므로 전략에 대한 지식이 필요하다.
   • 이는 클라이언트의 복잡성을 증가시킬 수 있다.
3. 데이터 공유 문제
   • 여러 전략 간에 데이터를 공유해야 할 경우 복잡해질 수 있다.
   • 컨텍스트를 통해 데이터를 전달하거나 전략 클래스 간의 통신이 필요할 수 있다.
4. 미사용 전략으로 인한 오버헤드
   • 모든 전략을 미리 구현해 놓으면 실제로 사용하지 않는 전략도 메모리에 로드된다.
   • 이는 리소스 낭비를 초래할 수 있다.

 

📌 정리

전략 패턴은 행위를 캡슐화하고 런타임에 알고리즘을 바꿀 수 있게 해주는 유연한 디자인 패턴이다.

이 패턴은 알고리즘을 사용하는 컨텍스트와 알고리즘의 구현을 분리함으로써 결합도를 낮추고 확장성을 높여준다. 다양한 알고리즘이 필요하고 실행 중에 이를 교체해야 하는 상황에서 특히 유용하지만, 클래스 수 증가와 클라이언트의 책임 증가라는 단점도 고려해야 한다.

 

✅ 언제 사용하면 좋을까?

• 비슷한 기능을 하지만 다른 알고리즘을 사용해야 할 때
• 런타임에 알고리즘을 동적으로 교체해야 할 때
• 알고리즘의 세부 구현을 클라이언트로부터 숨기고 싶을 때
• 조건문이 많고 복잡해지는 경우(if-else 또는 switch-case가 많을 때)

❌ 언제 피해야 할까?

• 알고리즘이 거의 변경되지 않을 때
• 알고리즘이 단순하여 캡슐화할 필요가 없을 때
• 전략의 수가 너무 많아서 관리가 복잡해질 때
• 성능이 중요한 경우(추가적인 객체 생성으로 인한 오버헤드)

 

📊 템플릿 메서드 패턴과 비교

항목	템플릿 메서드 패턴	전략 패턴
구현 방식	상속을 통해 구현	합성(composition)을 통해 구현
알고리즘 교체	컴파일 타임에 결정	런타임에 동적으로 교체 가능
구조	상위 클래스가 알고리즘 골격 정의	인터페이스를 통해 알고리즘 캡슐화
코드 재사용	상위 클래스 코드 재사용	알고리즘 클래스 재사용
주요 관계	부모-자식 관계(is-a)	인터페이스-구현 관계(has-a)
유연성	상대적으로 낮음	높음(실행 중 교체 가능)
확장성	하위 클래스 추가로 확장	새로운 전략 클래스 추가로 확장

 

 

📋 참고

• https://refactoring.guru/ko/design-patterns/strategy