전략 패턴(Strategy Pattern)은 객체지향 설계에서 사용되는 디자인 패턴 중 하나로, 알고리즘군을 각각의 클래스에 캡슐화하고, 이들을 런타임에 교환할 수 있게 함으로써 클라이언트가 알고리즘의 구현에 의존하지 않도록 설계한다. 이 패턴은 주로 다음과 같은 구조적 요소로 구성된다.
-
Context(컨텍스트)
- 전략 객체를 사용하며, 전략을 실행하기 위한 인터페이스를 제공한다.
- 전략을 교체할 수 있는 메서드(예:
setStrategy)를 포함한다.
-
Strategy(전략) 인터페이스
- 구체적인 알고리즘을 구현하는 메서드를 선언한다.
- 모든 구체 전략 클래스는 이 인터페이스를 구현한다.
-
ConcreteStrategy(구체 전략) 클래스들
- Strategy 인터페이스를 구현하여 서로 다른 알고리즘을 제공한다.
- 예를 들어 정렬 알고리즘을 선택하는 경우
BubbleSortStrategy,QuickSortStrategy등이 해당한다.
주요 목적
- 알고리즘의 독립성: 클라이언트 코드와 알고리즘 구현을 분리하여 유지보수를 용이하게 한다.
- 동적 교체: 실행 시점에 전략을 교체할 수 있어 상황에 따라 최적의 알고리즘을 선택할 수 있다.
- 중복 최소화: 동일한 작업을 수행하는 여러 알고리즘을 하나의 인터페이스 아래 통합함으로써 코드 중복을 줄인다.
적용 사례
- 정렬, 검색, 압축 등 다양한 알고리즘을 동적으로 선택해야 하는 경우.
- 게임 AI에서 캐릭터의 행동 방식을 전략 객체로 정의하고 상황에 따라 교체.
- UI 레이아웃에 따라 다른 레이아웃 전략을 적용하는 경우.
관련 패턴
- 템플릿 메서드 패턴과는 달리, 전략 패턴은 알고리즘 전체를 교체 가능하게 하는 반면, 템플릿 메서드 패턴은 알고리즘의 골격을 고정하고 일부 단계만을 서브클래스가 구현하도록 한다.
- 상태 패턴과 유사하게 동작을 변경하지만, 전략 패턴은 행동 자체를 교체하는 반면 상태 패턴은 객체의 내부 상태에 따라 동작이 달라진다.
한계와 주의점
- 전략 객체가 많아질 경우 관리가 복잡해질 수 있다.
- 전략을 빈번히 교체하면 성능에 영향을 미칠 수 있다(특히 전략 객체 생성 비용이 큰 경우).
전략 패턴은 1994년 에리히 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스가 공동 집필한 Design Patterns: Elements of Reusable Object‑Oriented Software에 공식적으로 소개되었으며, 이후 다양한 프로그래밍 언어와 프레임워크에서 널리 채택되고 있다.
