디자인 패턴

소프트웨어 설계 과정에서 반복적으로 발생하는 문제들에 대해 검증된 해결책을 정형화한 모범 사례라고 정의할 수 있다.

전략 패턴 (Strategy Pattern)

실행 중에 알고리즘을 선택할 수 있게 하는 패턴

• 알고리즘을 선택한다?
  • 특정 기능을 수행하는 여러 가지 방식 중 상황에 맞는 하나를 런타임에 동적으로 결정한다
  • 실제 처리 로직을 인터페이스 뒤로 숨기고 클라이언트가 필요한 로직을 선택해 사용할 수 있게 만드는 것

핵심 구조

객체가 할 수 있는 행위들을 각각 전략(Strategy)이라는 클래스로 캡슐화하고, 이들을 인터페이스를 통해 추상화한다.

• Strategy (인터페이스) : 모든 지원하는 알고리즘에 공통적인 인터페이스를 정의한다.
• ConcreteStrategy (구현체) : 실제 알고리즘을 구현한 클래스들이다.
• Context (문맥) : Strategy를 사용하는 역할을 하며, 필요애 따라 전략 객체를 교체할 수 있다.

예시

결제 시스템에서 결제 수단(카드, 네이버페이, 카카오페이)에 따라 결제 로직이 달라지는 경우를 생각해보자.

• PaymentStrategy를 인터페이스를 정의한다
• CardPayment, NaverPayPayment, KakaoPayPayment 등의 실제 전략 구현체들을 정의한다.
• PaymentService 는, 런타임에 실제 구현체들을 사용해서 결제를 처리한다.

장단점

• OCP(개방-폐쇄 원칙) 준수 : 새로운 결제 수단이 추가되어도 기존 PaymentService 코드를 수정할 필요 없이, 새로운 PaymentStrategy 구현체만 추가하면 된다.

언제 사용하면 좋을까?

• 유사한 행위들이 데이터만 다른게 아니라 로직 자체가 다를 때
• 하나의 클래스 안에 if-else 분기가 너무 많아져 가독성을 해칠 때
• 런타임 중에 객체의 알고리즘을 동적으로 변경해야 할 때