[디자인패턴] 전략 패턴 , 스트래티지 패턴 (Strategy Pattern)

 

1. 정의

💡 전략 패턴 , 스트래티지 패턴 (strategy pattern)
알고리즘군을 정의하고 각각 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지 패턴을 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

'행위(Behavioral) 패턴'

행위를 클래스로 캡슐화해 동적으로 (전략에 맞게) 행위를 자유롭게 바꿀 수 있게 해주는 패턴

 

전략(Strategy)을 쉽게 바꿀 수 있도록 해주는 패턴

여기서 전략이란? 어떤 목적을 달성하기 위해 일을 수행하는 방식. 비즈니스 규칙, 문제해결 알고리즘 등

 

2. [예제] 오리게임 어플리케이션

// 오리 슈퍼클래스
public abstract class Duck {
    public Duck() {}

    public void quack() {
        System.out.println("꽥~~");
    }

    public void swim() {
        System.out.println("수영한다~~");
    }

    public abstract void display(); // 구체적인 오리에서 재정의
}
// Duck 을 확장하여 ReadHeadDuck 정의
public class RedHeadDuck extends Duck {
    @Override
    public void display() {
        System.out.println("RedHeadDuck.display() 출력");
    }
}
// Duck 을 확장하여 MallardDuck 정의
public class MallardDuck extends Duck {
    @Override
    public void display() {
        System.out.println("MallardDuck.display() 출력");
    }
}

(1) 문제 1 : 상속에 의한 문제

요구사항 : 오리가 날 수 있게 해주세요. 그리고 Rubber Duck 도 추가해주세요. 근데 이 고무오리는 날 수 없어요.

// 오리 슈퍼클래스
public abstract class Duck {
    public Duck() {}

    public void quack() {
        System.out.println("꽥~~");
    }

    public void swim() {
        System.out.println("수영한다~~");
    }
    // 날 수 있게 기능 추가
    public void fly() {
        System.out.println("오리날다~~");
    }
    
    public abstract void display(); // 구체적인 오리에서 재정의
}
// Duck 을 확장하여 RubberDuck 정의 (날 수 없는 오리 추가)
public class RubberDuck extends Duck {
    @Override
    public void display() {
        System.out.println("RubberDuck.display() 출력");
    }

    @Override
    public void fly() {
        // 상속때문에 영향이 있어 날수 없도록 재정의 했다.
        System.out.println("고무오리는 못 날아요");
    }
}

• 날 수 있는 기능을 추가해주세요. : Duck 추상클래스에 날 수 있는 기능 fly() 를 추가해서 해결했다.
• Rubber Duck 를 추가해주세요. : Duck 클래스를 확장해서 RubberDuck 를 정의했다.
• 근데, Rubber Duck은 날 수 없어요. : Duck 클래스를 상속받고 있어 날고있다. fly() 를 재정의해서 날 수 없게 했다.

 

문제는 얼추 해결된 것으로 보인다.

그런데, 앞으로 Rubber Duck과같이 날 수 없는 오리가 또 추가된다면 그때마다 메소드를 하나하나 확인하며 오버라이드 해서 구현해줘야한다.

 

(2) 문제 2 : 인터페이스에 의한 문제

회사에서 1개월마다 새로운 오리를 업데이트 할 예정이라고 한다. 또 각각의 특성도 다양할 것이라고 한다. 꽥 하는 소리도 다 다르고, 날 수 없는 오리도 있을 것이라고 한다. 현재 시스템은 상속으로 오리를 생성하고 있기때문에 오리가 추가 될 때마다 quack() 메소드와 fly() 메소드를 다 살펴봐야 한다.

이러면 상속활용이 타당하지 않다. 그렇다면 인터페이스를 사용해보면 어떨까?

// fly 인터페이스
public interface Flyable {
    void fly();
}
// quack 인터페이스
public interface Quackable {
    void quack();
}
// RubberDuck : Duck 을 상속받고, Flyable 과 Quackable 인터페이스를 구현
public class RubberDuck extends Duck implements Flyable, Quackable {
    @Override
    public void display() {
        System.out.println("RubberDuck.display() 출력");
    }
    // 인터페이스 구현
    public void fly() {
        System.out.println("고무오리는 못 날아요");
    }
    public void quack(){
        System.out.println("꾸액");
    }
}

인터페이스를 사용하면 각 서브클래스에서 모든 인터페이스를 구현해주어야 하니 코드 중복이 엄청나게 발생한다. 메소드 몇개 오버라이드 해야하는 것을 피하려다가 모든 Duck 의 서브클래스를 전부 고쳐야 하게 되버린다.

 

3. 다른 해결방법

위에서 확인한 문제점 2가지

1. 상속을 사용하는 방법은 서브클래스들의 행동이 바뀔 수 있는데도 모든 서브클래스들이 하나의 행동을 사용하는 것이 문제가 된다.
2. Flyable, Quackable 인터페이스를 사용하는 방법은 코드재사용을 할 수 없다. 즉, 한가지의 행동을 바꿀때마다 그 행동이 정의되어 있는 모든 서브클래스들을 전부 찾아서 코드를 고쳐줘야하고, 그 과정에서 예기치못한 새로운 버그가 발생할 가능성이 매우 높다.

📌 디자인원칙
어플리케이션에서 달라지는 부분들 찾아내고, 달라지지 않는 부분으로부터 분리시킨다.
달라지는 부분을 찾아내서 나머지 코드에 영향을 주지 않도록 캡슐화 시켜준다.

 

달라지는 부분 : fly(), quack() -> Duck 클래스로부터 분리시키기위해 각 행동을 나타낼 클래스의 집합을 만들어주자.

// fly 행동 클래스 집합
public interface FlyBehavior {
    void fly();
}
// quack 행동 클래스 집합
public interface QuackBehavior {
    void quack();
}
// 날 수 없는 행동 구현 : FlyNoWay (행동을 위임)
public class FlyNoWay implements FlyBehavior {
    public void fly() {
        System.out.println("못 날아요!");
    }
}
// 날 수 있는 행동 구현 : FlyWithWings (행동을 위임)
public class FlyWithWings implements FlyBehavior {
    public void fly() {
        System.out.println("날고 있어요!");
    }
}
// 꽥 구현 : QuackBehavior (행동을 위임)
public class Quack implements QuackBehavior {
    public void quack() {
        System.out.println("꽥");        
    }
}
// 가짜 꽥 구현 : QuackBehavior (행동을 위임)
public class FakeQuack implements QuackBehavior {
    public void quack() {
        System.out.println("꾸애액");        
    }
}

이렇게 행동을 분리시킨다. 행동에 관한 인터페이스가 생기고 구체적인 행동을 구현하는 클래스들이 각각 생성된다.

이제 더이상 나는 행동 fly() 와 소리내는 행동 quack() 를 Duck 클래스나 그 서브클래스에서 구현하지 않고 다른 클래스에 위임을 해주게 된다.

📌 디자인원칙
상속보다는 구성을 활용한다.

📌 디자인원칙
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.

// Duck 클래스에서 이제 행동을 직접처리 하지않고 각 행동을 참조하고 위임해준다.
public abstract class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;

    public Duck() {}

    public void setFlyBehavior(FlyBehavior flyBehavior) {
        this.flyBehavior = flyBehavior;
    }
    public void setQuackBehavior(QuackBehavior quackBehavior) {
        this.quackBehavior = quackBehavior;
    }
    public void performFly() {
        flyBehavior.fly();
    }
    public void performQuack() {
        quackBehavior.quack();
    }

    public void swim() {
        System.out.println("수영한다~~");
    }

    public abstract void display();
}

"A 는 B 이다" 보다 "A 에는 B 가 있다" 가 나을 수 있다.

각각의 오리들에게는 FlyBehavior 와 QuackBehavior 이 있으며 각각 나는 행동과 소리내는 행동을 위임받는다.

이런식으로 두 클래스를 합치는 것을 구성 (composition) 을 이용하는 것이라고 한다.

여기의 오리 클래스는 행동을 상속받는 대신 올바른 행동 객체로 구성됨으로써 행동을 부여받게 된다.

 

4. 예제2

1. Strategy 인터페이스

public interface Strategy {
    void algorithmInterface();
}

2. Strategy 인터페이스를 구현 ( 각 전략을 구현한다)

// 전략 A 구현
@Slf4j
public class StrategyLogicA implements Strategy {
    @Override
    public void algorithmInterface() {
        log.info("전략 인터페이스 구현 A");
    }
}
// 전략 B 구현
@Slf4j
public class StrategyLogicB implements Strategy {
    @Override
    public void algorithmInterface() {
        log.info("전략 인터페이스 구현 B");
    }
}

3. 전략을 사용하는 Context

@Slf4j
public class Context {

    public void execute(Strategy strategy) {
        Long startTime = System.currentTimeMillis();

        // 비즈니스 로직 실행
        strategy.algorithmInterface(); // 각 전략에 위임
        // 비즈니스 로직 종료

        Long endTime = System.currentTimeMillis();
        Long resultTime = endTime - startTime;
        log.info("resultTime = {}", resultTime); // 실행시간 출력
    }
    
}

4. 실행

/**
 * 전략 패턴 적용
 */
@Test
void strategy1() {
    Context context = new Context();
    context.execute(new StrategyLogicA()); // Context의 로직 실행시 파라미터로 전략 전달
    context.execute(new StrategyLogicB());
}
/**
 * 전략 패턴 익명 내부 클래스, 람다 사용하는 경우
 */
@Test
void strategy2() {
    Context context = new Context();
    context.execute(new Strategy() { // 익명 내부 클래스 가능
        @Override
        public void algorithmInterface() {
            log.info("전략 인터페이스 구현 - A");
        }
    });
    context.execute(() -> log.info("전략 인터페이스 구현2")); // 람다 가능
}

5. 출력결과 확인

// strategy1 결과 (로그의 패키지명 생략)
..생략..StrategyLogicA - 전략 인터페이스 구현 A
..생략..Context - resultTime = 11
..생략..StrategyLogicB - 전략 인터페이스 구현 B
..생략..Context - resultTime = 0
// strategy2 결과 (로그의 패키지명 생략)
..생략..ContextTest - 전략 인터페이스 구현 - A
..생략..Context - resultTime = 1
..생략..ContextTest - 전략 인터페이스 구현2
..생략..Context - resultTime = 1

 

5. UML Class Diagram

 

6. GOF 디자인 패턴 정의

알고리즘 제품군을 정의하고 각각을 캡슐화하여 상호 교환 가능하게 만들자. 전략을 사용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

전략 패턴은 변하지 않는 부분을 Context (문맥) 라는 곳에 두고, 변하는 부분을 Strategy 라는 인터페이스를 만들고 해당 인터페이스를 구현하도록 해서 문제를 해결한다. Context 의 내부 필드에 Strategy 를 주입해서 사용한다. 상속이 아니라 위임으로 문제를 해결한다.

 

■ Context 의 내부에 Strategy 를 두고 사용하는 방식

Context 와 Strategy 를 한번 조립하고 나면 이후로는 Context 를 실행하기만 하면 된다. 스프링으로 어플리케이션을 개발할 때 로딩되는 시점에 필요한 의존관계를 주입해두고 실제 요청을 처리하는 것과 같은 원리이다.

단점은 Context 와 Strategy 를 조립한 이후에는 전략을 변경하기가 번거롭다는 점이다. Context 에 setter 를 만들어 Strategy 를 넘겨 변경하면 되지만, Context 를 싱글톤으로 사용하면 동시성 이슈등의 문제가 발생할 수 있다.

그래서 전략을 실시간으로 변경해야 하면 차라리 Context 를 하나 더 생성해서 다른 Strategy 를 주입하는 것이 더 나은 선택이 될 수 있다.

---

참고
헤드 퍼스트 디자인 패턴 (Head First Design Patterns) - 에릭 프리먼,엘리자베스 롭슨,케이시 시에라,버트 베이츠