맨위로가기

전략 패턴

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

전략 패턴은 객체 지향 프로그래밍에서 알고리즘을 캡슐화하여, 런타임에 알고리즘을 선택하여 사용할 수 있도록 하는 디자인 패턴이다. 이 패턴은 Context 클래스가 Strategy 인터페이스를 참조하여 알고리즘을 수행하도록 설계된다. Strategy 인터페이스를 구현하는 ConcreteStrategy 클래스들은 실제 알고리즘을 캡슐화한다. 전략 패턴은 개방/폐쇄 원칙을 준수하며, 상속 대신 컴포지션을 사용하여 유연성을 높인다. Java, C#, Python 등 다양한 프로그래밍 언어에서 구현될 수 있으며, 함수, 인터페이스, 델리게이트 등을 활용하여 구현한다.

더 읽어볼만한 페이지

  • 소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
    모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다.
  • 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
    스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.
  • 표시 이름과 문서 제목이 같은 위키공용분류 - 라우토카
    라우토카는 피지 비치레부섬 서부에 위치한 피지에서 두 번째로 큰 도시이자 서부 지방의 행정 중심지로, 사탕수수 산업이 발달하여 "설탕 도시"로 알려져 있으며, 인도에서 온 계약 노동자들의 거주와 미 해군 기지 건설의 역사를 가지고 있고, 피지 산업 생산의 상당 부분을 담당하는 주요 기관들이 위치해 있다.
  • 표시 이름과 문서 제목이 같은 위키공용분류 - 코코넛
    코코넛은 코코넛 야자나무의 열매로 식용 및 유지로 사용되며, 조리되지 않은 과육은 100g당 354kcal의 열량을 내는 다양한 영양 성분으로 구성되어 있고, 코코넛 파우더의 식이섬유는 대부분 불용성 식이섬유인 셀룰로오스이며, 태국 일부 지역에서는 코코넛 수확에 훈련된 원숭이를 이용하는 동물 학대 문제가 있다.
  • 한국어 위키백과의 링크가 위키데이터와 같은 위키공용분류 - 라우토카
    라우토카는 피지 비치레부섬 서부에 위치한 피지에서 두 번째로 큰 도시이자 서부 지방의 행정 중심지로, 사탕수수 산업이 발달하여 "설탕 도시"로 알려져 있으며, 인도에서 온 계약 노동자들의 거주와 미 해군 기지 건설의 역사를 가지고 있고, 피지 산업 생산의 상당 부분을 담당하는 주요 기관들이 위치해 있다.
  • 한국어 위키백과의 링크가 위키데이터와 같은 위키공용분류 - 코코넛
    코코넛은 코코넛 야자나무의 열매로 식용 및 유지로 사용되며, 조리되지 않은 과육은 100g당 354kcal의 열량을 내는 다양한 영양 성분으로 구성되어 있고, 코코넛 파우더의 식이섬유는 대부분 불용성 식이섬유인 셀룰로오스이며, 태국 일부 지역에서는 코코넛 수확에 훈련된 원숭이를 이용하는 동물 학대 문제가 있다.
전략 패턴
개요
유형행위 디자인 패턴
의도알고리즘군을 정의하고, 각 알고리즘을 캡슐화하여 알고리즘을 동적으로 선택할 수 있게 한다.
별칭정책 (Policy)
분류객체 지향 디자인 패턴
구조
전략 패턴 구조 다이어그램
전략 패턴 구조 다이어그램
참여자
전략 (Strategy)알고리즘 또는 행동을 위한 인터페이스를 정의한다.
구체적인 전략 (ConcreteStrategy)전략 인터페이스를 구현한다.
문맥 (Context)전략 객체를 사용하여 클라이언트에 원하는 행동을 제공한다.
협업
문맥적절한 행동을 위해 전략 인터페이스를 호출한다.
문맥클라이언트로부터 요청을 받아서 전략 객체에 전달할 수 있다.
결과
장점알고리즘군을 쉽게 추가하거나 변경할 수 있다.
클라이언트 코드를 변경하지 않고 알고리즘을 변경할 수 있다.
코드 중복을 줄일 수 있다.
단일 책임 원칙을 준수한다.
개방/폐쇄 원칙을 준수한다.
단점클라이언트는 사용 가능한 전략에 대해 알아야 한다.
전략 객체 수가 증가할 수 있다.
사용 사례
예시정렬 알고리즘 (예: 퀵 정렬, 병합 정렬)
압축 알고리즘 (예: ZIP, GZIP)
결제 방식 (예: 신용 카드, 현금)
적용 시점여러 알고리즘 중 하나를 동적으로 선택해야 할 때
알고리즘군을 쉽게 확장해야 할 때
알고리즘의 구현 세부 사항을 클라이언트로부터 숨겨야 할 때
구현
고려 사항전략 객체의 생성 및 관리를 누가 담당할 것인가?
전략 객체 간의 통신은 어떻게 할 것인가?
전략 객체를 캐싱할 필요가 있는가?
관련 패턴
템플릿 메서드 패턴알고리즘의 뼈대를 정의하고, 일부 단계를 하위 클래스에서 구현하도록 한다.
상태 패턴객체의 내부 상태가 변경될 때 객체의 행동을 변경할 수 있도록 한다.
브리지 패턴추상화와 구현을 분리하여 독립적으로 변경할 수 있도록 한다.

2. 구조

전략 패턴은 특정 작업을 수행하는 다양한 알고리즘(전략)들을 각각의 클래스로 캡슐화하고, 이들을 필요에 따라 교체하여 사용할 수 있도록 하는 디자인 패턴이다. 이 패턴의 주요 구성 요소는 다음과 같다.


  • 컨텍스트 (Context): 클라이언트가 사용하는 객체로, 내부에 전략 객체에 대한 참조를 유지한다. 컨텍스트는 전략 인터페이스를 통해 실제 작업을 수행할 구체적인 전략 객체에게 요청을 전달한다.
  • 전략 인터페이스 (Strategy Interface): 모든 구체적인 전략 클래스들이 구현해야 하는 공통의 연산(메서드)을 정의하는 인터페이스이다. 컨텍스트는 이 인터페이스 타입의 참조를 통해 전략 객체와 소통한다.
  • 구체적인 전략 (Concrete Strategy): 전략 인터페이스를 구현하는 실제 클래스들이다. 각각의 구체적인 전략 클래스는 특정 알고리즘이나 행동 방식을 캡슐화하여 구현한다.


이 구조를 통해 컨텍스트는 어떤 구체적인 전략이 사용되는지 알 필요 없이 일관된 방식으로 작업을 요청할 수 있으며, 실행 중에 필요에 따라 다른 전략으로 쉽게 교체할 수 있다. 이는 코드의 유연성을 높이고 새로운 전략을 추가하기 쉽게 만든다. 상세한 클래스 구조와 객체 간의 상호작용은 아래 UML 다이어그램 섹션에서 확인할 수 있다.

2. 1. UML 클래스 및 시퀀스 다이어그램

오른쪽


위의 UML 클래스 다이어그램에서 Context 클래스는 특정 알고리즘을 직접 구현하지 않는다. 대신, Context는 알고리즘을 수행하기 위해 Strategy 인터페이스(strategy.algorithm())를 참조한다. 이를 통해 Context는 구체적인 알고리즘 구현 방식에 얽매이지 않고 독립성을 유지할 수 있다. Strategy1Strategy2 클래스는 Strategy 인터페이스를 실제로 구현하는 구체적인 전략 클래스들로, 각각의 알고리즘을 내부에 포함(캡슐화)한다.

UML 시퀀스 다이어그램은 프로그램 실행 중 객체 간의 상호작용을 보여준다. Context 객체는 필요에 따라 알고리즘 실행을 서로 다른 Strategy 객체에게 위임한다. 예를 들어, Context는 먼저 Strategy1 객체의 algorithm() 메소드를 호출한다. Strategy1은 해당 알고리즘을 수행하고 그 결과를 Context에게 반환한다. 이후 Context는 현재 전략을 Strategy2로 변경하고, Strategy2 객체의 algorithm() 메소드를 호출할 수 있다. Strategy2 역시 알고리즘을 수행한 뒤 결과를 Context에게 반환한다. 이러한 방식으로 런타임에 동적으로 알고리즘을 교체할 수 있다.

2. 2. 클래스 다이어그램

UML로 나타낸 전략 패턴


UML 클래스 다이어그램에서 Context 클래스는 특정 알고리즘을 직접 구현하지 않는다. 대신, Context는 알고리즘을 수행하기 위해 Strategy 인터페이스를 참조한다(예: `strategy.algorithm()`). 이러한 구조 덕분에 Context는 실제 알고리즘이 어떻게 구현되는지에 대해 알 필요가 없으며, 구현 방식으로부터 독립적이다. Strategy1, Strategy2와 같은 구체적인 전략 클래스(ConcreteStrategy)들은 Strategy 인터페이스를 구현하며, 각각의 구체적인 알고리즘을 캡슐화하여 구현한다.

UML 시퀀스 다이어그램은 이러한 클래스들이 실행 시간에 어떻게 상호작용하는지를 보여준다. Context 객체는 실제 알고리즘 실행을 구체적인 Strategy 객체에게 위임한다. 예를 들어, Context는 먼저 Strategy1 객체의 `algorithm()` 메서드를 호출한다. Strategy1 객체는 해당 알고리즘을 수행하고 그 결과를 Context에게 반환한다. 이후 Context는 필요에 따라 현재 사용 중인 전략을 Strategy2로 변경하고, Strategy2 객체의 `algorithm()` 메서드를 호출할 수 있다. Strategy2 객체 역시 맡겨진 알고리즘을 수행하고 결과를 Context에게 반환한다.[4][5]

LePUS3 표기법으로 나타낸 전략 패턴 ([https://web.archive.org/web/20180314162121/http://www.lepus.org.uk/ref/legend/legend.xml 범례])

3. 전략 패턴과 개방/폐쇄 원칙

전략 패턴[8]에 따르면 클래스의 동작은 상속되어서는 안 되며, 대신 인터페이스를 사용하여 캡슐화해야 한다. 이는 클래스가 확장에 열려 있지만 수정에는 닫혀 있어야 한다는 개방/폐쇄 원칙(OCP)을 준수하는 방식이다.

예를 들어 자동차 클래스를 생각해 보자. 자동차의 두 가지 주요 기능은 ''브레이크''와 ''가속''이다. 이 기능들의 동작 방식은 모델마다 자주 달라지므로, 일반적으로는 각 기능을 하위 클래스에서 구현하는 방식을 사용한다. 하지만 이 접근 방식에는 상당한 단점이 있다. 가속 및 브레이크 동작은 새로운 자동차 모델이 나올 때마다 다시 선언해야 하며, 모델 수가 증가함에 따라 이러한 동작을 관리하는 작업량이 크게 늘어나고 모델 간 코드 중복이 발생한다. 또한, 각 모델의 코드 내용을 직접 확인하지 않고서는 해당 모델의 동작 특성을 정확히 파악하기 어렵다.

전략 패턴은 상속 대신 컴포지션을 사용하여 이 문제를 해결한다. 전략 패턴에서는 동작을 별도의 인터페이스와 이 인터페이스를 구현하는 특정 클래스들로 정의한다. 이를 통해 동작과 그 동작을 사용하는 클래스 간의 분리가 명확해진다. 동작을 사용하는 클래스를 변경하지 않고도 동작 자체를 수정할 수 있으며, 클래스는 큰 코드 변경 없이 사용하는 특정 구현을 바꾸는 것만으로 동작 간 전환이 가능하다. 동작은 설계 시점뿐만 아니라 프로그램 실행 중(런타임)에도 변경할 수 있다. 예를 들어, 자동차 객체의 브레이크 동작을 `BrakeWithABS()`에서 `Brake()`로 변경하려면 `brakeBehavior` 멤버 변수를 다음과 같이 수정하면 된다.

```cpp

brakeBehavior = new Brake();

```

전략 패턴의 구조


아래는 전략 패턴을 적용한 자바(Java) 코드 예시이다.

```java

/* 알고리즘 캡슐화 계열: 인터페이스와 구현 */

public interface IBrakeBehavior {

public void brake();

}

public class BrakeWithABS implements IBrakeBehavior {

public void brake() {

System.out.println("Brake with ABS applied");

}

}

public class Brake implements IBrakeBehavior {

public void brake() {

System.out.println("Simple Brake applied");

}

}

/* 위의 알고리즘을 상호 교환적으로 사용할 수 있는 클라이언트 */

public abstract class Car {

private IBrakeBehavior brakeBehavior;

public Car(IBrakeBehavior brakeBehavior) {

this.brakeBehavior = brakeBehavior;

}

public void applyBrake() {

brakeBehavior.brake();

}

public void setBrakeBehavior(IBrakeBehavior brakeType) {

this.brakeBehavior = brakeType;

}

}

/* 클라이언트 1: 생성자에서 Brake 알고리즘 사용 */

public class Sedan extends Car {

public Sedan() {

super(new Brake());

}

}

/* 클라이언트 2: 생성자에서 BrakeWithABS 알고리즘 사용 */

public class SUV extends Car {

public SUV() {

super(new BrakeWithABS());

}

}

/* 자동차 예제 사용 */

public class CarExample {

public static void main(final String[] arguments) {

Car sedanCar = new Sedan();

sedanCar.applyBrake(); // "Simple Brake applied" 출력

Car suvCar = new SUV();

suvCar.applyBrake(); // "Brake with ABS applied" 출력

// 동적으로 브레이크 동작 변경

suvCar.setBrakeBehavior( new Brake() );

suvCar.applyBrake(); // "Simple Brake applied" 출력

}

}

```

이처럼 전략 패턴은 설계에 유연성을 부여하며, 개방/폐쇄 원칙을 효과적으로 따를 수 있도록 돕는다.

4. 예시

전략 패턴은 다양한 프로그래밍 언어 환경에서 각 언어의 특성을 살려 구현될 수 있다.

Java에서는 주로 클래스의 메서드 오버라이드와 인터페이스를 활용한 다형성을 통해 전략 패턴을 구현한다. Java 8 버전 이후부터는 메서드 참조나 함수형 인터페이스를 사용하여 더 간결한 구현도 가능하다.

파이썬의 경우, 함수가 일급 객체이기 때문에 별도의 클래스나 인터페이스 정의 없이 함수 자체를 전략으로 취급하여 전달하고 사용할 수 있다. 이는 콜백 함수를 사용하는 GUI 프로그래밍 등에서 흔히 발견되는 방식이다.

C#에서는 Java와 유사하게 클래스나 인터페이스 기반의 다형성을 이용할 수 있다. 하지만 전략으로 사용하는 알고리즘이 단일 메서드로 표현 가능하고 다른 객체 상태에 의존하지 않는다면, 상속 구조 없이 델리게이트를 활용하는 방식이 더 간결하여 선호되기도 한다.[6]

각 프로그래밍 언어별 구체적인 구현 코드 예시는 아래 하위 섹션들에서 자세히 확인할 수 있다.

4. 1. C#

다음은 C#을 사용한 예시이다. 첫 번째 예시는 인터페이스와 클래스를 이용한 기본적인 전략 패턴 구현을 보여준다.



public class StrategyPatternWiki

{

public static void Main(String[] args)

{

Customer firstCustomer = new Customer(new NormalStrategy());

// Normal billing

firstCustomer.Add(1.0, 1);

// Start Happy Hour

firstCustomer.Strategy = new HappyHourStrategy();

firstCustomer.Add(1.0, 2);

// New Customer

Customer secondCustomer = new Customer(new HappyHourStrategy());

secondCustomer.Add(0.8, 1);

// The Customer pays

firstCustomer.PrintBill();

// End Happy Hour

secondCustomer.Strategy = new NormalStrategy();

secondCustomer.Add(1.3, 2);

secondCustomer.Add(2.5, 1);

secondCustomer.PrintBill();

}

}

class Customer

{

private IList drinks;

// Get/Set Strategy

public IBillingStrategy Strategy { get; set; }

public Customer(IBillingStrategy strategy)

{

this.drinks = new List();

this.Strategy = strategy;

}

public void Add(double price, int quantity)

{

drinks.Add(Strategy.GetActPrice(price * quantity));

}

// Payment of bill

public void PrintBill()

{

double sum = 0;

foreach (double i in drinks)

{

sum += i;

}

Console.WriteLine("Total due: " + sum);

drinks.Clear();

}

}

interface IBillingStrategy

{

double GetActPrice(double rawPrice);

}

// Normal billing strategy (unchanged price)

class NormalStrategy : IBillingStrategy

{

public double GetActPrice(double rawPrice)

{

return rawPrice;

}

}

// Strategy for Happy hour (50% discount)

class HappyHourStrategy : IBillingStrategy

{

public double GetActPrice(double rawPrice)

{

return rawPrice * 0.5;

}

}



C#에서는 Java와 마찬가지로 클래스나 인터페이스를 사용한 다형성을 이용할 수 있다. 하지만, 전략으로 사용하는 알고리즘이 단일 메서드로 구현 가능하고 객체의 다른 속성이나 메서드에 접근할 필요가 없는 경우에는, 상속 관계 없이 델리게이트(delegate)를 사용하는 것이 더 간결하고 선호되는 방식이다.[6] 다음은 델리게이트를 사용한 예시이다.



using System;

// MainApp 테스트 애플리케이션.

public class MainApp

{

public static void Main()

{

Context context;

// 다른 알고리즘에 따르는 3개의 컨텍스트.

context = new Context(new ConcreteStrategyA().Execute);

context.Execute();

context = new Context(new ConcreteStrategyB().Execute);

context.Execute();

context = new Context(new ConcreteStrategyC().Execute);

context.Execute();

}

}

// 구체적인 전략을 구현하는 클래스는, 이 델리게이트에 적합한 메서드를 구현한다.

// 컨텍스트 클래스는, 구체적인 전략을 호출하기 위해 이 델리게이트를 사용한다.

public delegate void ExecuteStrategyDelegate();

class ConcreteStrategyA

{

public void Execute()

{

Console.WriteLine("Called ConcreteStrategyA.Execute()");

}

}

class ConcreteStrategyB

{

public void Execute()

{

Console.WriteLine("Called ConcreteStrategyB.Execute()");

}

}

class ConcreteStrategyC

{

public void Execute()

{

Console.WriteLine("Called ConcreteStrategyC.Execute()");

}

}

// ExecuteStrategyDelegate 객체에 대한 참조를 보존한다.

class Context

{

ExecuteStrategyDelegate executeStrategy;

// Constructor

public Context(ExecuteStrategyDelegate executeStrategy)

{

this.executeStrategy = executeStrategy;

}

public void Execute()

{

this.executeStrategy();

}

}


4. 2. Java

Java에서는 클래스의 메서드 오버라이드를 사용한 다형성을 통해 전략 패턴을 구현할 수 있다. 특히 인터페이스를 활용하는 방식이 일반적이다.

아래는 인터페이스를 사용하여 전략 패턴을 구현한 Java 코드 예시이다.



package org.wikipedia.patterns.strategy;

// MainApp: 전략 패턴 사용 예시를 보여주는 테스트 애플리케이션

class MainApp {

public static void main(String[] args) {

Context context;

// 다양한 전략(알고리즘) 객체를 생성하여 Context에 주입하고 실행한다.

// 1. ConcreteStrategyA 전략 사용

context = new Context(new ConcreteStrategyA());

context.executeStrategy(); // "Called ConcreteStrategyA.execute()" 출력

// 2. ConcreteStrategyB 전략 사용

context = new Context(new ConcreteStrategyB());

context.executeStrategy(); // "Called ConcreteStrategyB.execute()" 출력

// 3. ConcreteStrategyC 전략 사용

context = new Context(new ConcreteStrategyC());

context.executeStrategy(); // "Called ConcreteStrategyC.execute()" 출력

}

}

// Strategy 인터페이스: 모든 구체적인 전략 클래스가 구현해야 할 메서드를 정의한다.

// Context 클래스는 이 인터페이스 타입을 통해 구체적인 전략 객체와 상호작용한다.

interface Strategy {

void execute(); // 실행할 알고리즘의 인터페이스 메서드

}

// ConcreteStrategyA: Strategy 인터페이스를 구현하는 구체적인 전략 클래스 1

class ConcreteStrategyA implements Strategy {

@Override

public void execute() {

System.out.println("Called ConcreteStrategyA.execute()");

}

}

// ConcreteStrategyB: Strategy 인터페이스를 구현하는 구체적인 전략 클래스 2

class ConcreteStrategyB implements Strategy {

@Override

public void execute() {

System.out.println("Called ConcreteStrategyB.execute()");

}

}

// ConcreteStrategyC: Strategy 인터페이스를 구현하는 구체적인 전략 클래스 3

class ConcreteStrategyC implements Strategy {

@Override

public void execute() {

System.out.println("Called ConcreteStrategyC.execute()");

}

}

// Context 클래스: 특정 Strategy 객체를 사용하여 작업을 수행한다.

// 생성 시 구체적인 전략 객체를 받아 Strategy 타입의 참조 변수에 저장한다.

class Context {

private Strategy strategy; // 현재 컨텍스트에 설정된 전략 객체

// 생성자: 사용할 전략 객체를 외부에서 주입받는다.

public Context(Strategy strategy) {

this.strategy = strategy;

}

// 전략 실행 메서드: 현재 설정된 strategy 객체의 execute 메서드를 호출한다.

// 메서드 이름을 executeStrategy 등으로 변경하여 역할 명확화 가능 (예시에서는 execute 유지)

public void executeStrategy() { // 원본의 execute() 메서드

this.strategy.execute();

}

}



위 코드에서 `Strategy`는 알고리즘 실행 메서드(`execute`)를 정의하는 인터페이스이다. `ConcreteStrategyA`, `ConcreteStrategyB`, `ConcreteStrategyC`는 각각 `Strategy` 인터페이스를 구현하여 구체적인 알고리즘 로직을 제공한다. `Context` 클래스는 생성자를 통해 특정 `Strategy` 구현 객체를 전달받아 내부 필드(`strategy`)에 저장한다. `Context`의 `executeStrategy` (또는 `execute`) 메서드가 호출되면, 현재 저장된 `strategy` 객체의 `execute` 메서드를 호출하여 해당 알고리즘을 실행한다. `MainApp` 클래스는 이 구조를 활용하여, 런타임에 `Context`가 사용할 전략을 동적으로 변경하며 코드를 실행하는 예시를 보여준다.

4. 3. Python

파이썬에서는 함수가 일급 객체이기 때문에, 전략 패턴을 명시적으로 정의할 필요가 없는 경우가 많다. 함수 자체를 객체처럼 다룰 수 있어, 전략을 나타내는 함수를 직접 전달하고 사용할 수 있기 때문이다.

아래는 콜백 함수를 사용하는 GUI 프로그래밍에서 볼 수 있는 간단한 예시이다. `Button` 클래스는 초기화될 때 실행할 함수(`submit_func`)를 직접 받는다. 이 함수가 바로 전략에 해당한다.



class Button:

"""아주 기본적인 버튼 위젯"""

def __init__(self, submit_func, label):

self.on_submit = submit_func # 전략 함수를 직접 받음

self.label = label

# 서로 다른 전략(함수)을 가진 두 개의 버튼 인스턴스를 생성

# 첫 번째 버튼은 숫자의 합계를 계산하는 내장 함수 sum을 전략으로 사용

button1 = Button(sum, "Add 'em")

# 두 번째 버튼은 숫자를 문자열로 변환하여 공백으로 연결하는 람다 함수를 전략으로 사용

button2 = Button(lambda nums: " ".join(map(str, nums)), "Join 'em")

# 버튼을 테스트

numbers = range(1, 10) # 1부터 9까지의 숫자 리스트

# 각 버튼의 전략(on_submit 함수)을 실행

print(button1.on_submit(numbers)) # 출력: 45

print(button2.on_submit(numbers)) # 출력: 1 2 3 4 5 6 7 8 9



이 예시처럼, 파이썬에서는 별도의 전략 인터페이스나 클래스 없이도 함수 자체를 전략으로 활용하여 유연하게 코드를 작성할 수 있다.

참조

[1] 웹사이트 The Strategy design pattern - Problem, Solution, and Applicability http://w3sdesign.com[...] 2017-08-12
[2] 서적 Head First Design Patterns O'Reilly Media, Inc
[3] 서적 Design Patterns: Elements of Reusable Object-Oriented Software https://archive.org/[...] Addison Wesley
[4] 웹사이트 The Strategy design pattern - Structure and Collaboration http://w3sdesign.com[...] 2017-08-12
[5] 웹사이트 Design Patterns Quick Reference – McDonaldLand http://www.mcdonaldl[...]
[6] Microsoft Docs When to Use Delegates Instead of Interfaces (C# Programming Guide) https://docs.microso[...]
[7] 서적 Head First Design Patterns O'Reilly Media, Inc
[8] 서적 Design Patterns: Elements of Reusable Object-Oriented Software Addison Wesley
[9] 웹인용 The Strategy design pattern - Structure and Collaboration http://w3sdesign.com[...] 2017-08-12



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com