Strategy Pattern

들어가기 전에

전략패턴을 처음 들어본 것은 예전에 Java 스터디를 하면서 Next Challenge 과제 중 레이싱게임을 구현하는 것을 연습해보면서 였던 것 같다. 코드 리뷰 중에 레이싱카의 움직임에 대해 전략 패턴을 사용하면 어떠냐 라는 리뷰를 받은 적이 있었는데 그 때에는 전략 패턴이 왜 필요해서 써야되는지 감이 안 온 상태로 접근하게 된 것 같다. 이번에 전략 패턴에 대해서 정리해보고 전략 패턴이 객체지향관점에서 어떤 장점이 있는지 다뤄볼 예정입니다.

 

 

1. Strategy Pattern 기본 설명

전략 패턴의 기본적인 Flow는 아래의 이미지와 같습니다. 결국에 Interface를 쓰고 유연하게 그리고 느슨한 결합을 통해 설계를 할 수 있는 부분이 있는데 기존의 코드를 작성할 때와의 차이점을 한번 비교해보고자 합니다.

[조엘의 블로그] https://joel-dev.site/75

 

1.1 문제 제기

일반적으로 Class를 만들고 객체를 생성하고 method를 호출한다고 하자.

package com.example.designpattern.strategy;

public class Coffee {

    public void made() {
        System.out.println("커피가 만들어졌어요!");
    }
}

package com.example.designpattern.strategy;

public class Juice {

    public void order() {
        System.out.println("쥬스가 만들어졌어요!");
    }
}

package com.example.designpattern.strategy;

public class CafeMachine {
    private Order order;

    public void makeDrink() {
        // 음료를 만들건데 기존에 Coffee를 만드는 로직이 들어있다고 하자.
        if(order.getName().equals("coffee")) {
            Coffee coffee = new Coffee();
            coffee.made();
        } else if(order.getName().equals("juice")) {
            Juice juice = new Juice();
            juice.order();
            // 만약에 Client가 커피 이외에 식혜도 만들어서 제공을 하게 된다면?
        }
    }
}

이처럼 문제가 생기는데 기존의 Client는 단순히 Coffee 객체를 만든 뒤에 made() method를 호출하면 됬지만 비슷한 성향의 도메인이 늘어남에 따라 조건문이 추가되는 것을 알 수 있습니다. 또한 객체(음료 종류)별로 method 또한 다릅니다.

이 때 전략 패턴을 도입해보도록 하겠습니다.

 

1.2 Strategy Pattern 적용

package com.example.designpattern.strategy;

public interface Drink {
    void made();
}

public class Coffee implements Drink {

    // @Override
    public void made() {
        System.out.println("커피가 만들어졌어요!");
    }
}

public class Juice implements Drink{
    // @Override
    public void made() {
        System.out.println("쥬스가 만들어졌어요!");
    }
}

public class CafeMachine {
    private Drink drink;

    public void setOrderDrinkType(Drink drinkType) {
        this.drink = drinkType;
    }

    public void makeDrink() {
            drink.made();
    }
}

위의 전략 패턴을 사용하면 코드를 변경할 필요성이 없어지면서(객체가 늘어남에 따라 분기가 늘어나는 것) 단일책임원칙에 좀 더 부합되고, 확장성이 좋아지는 것을 알 수 있습니다. 느슨할 결합에 대해서도 해당이 됩니다.

 

물론 전략 패턴이 좋다고 해서 매번 써야하는 것은 아닙니다. 만일 객체의 교체가 자주 일어나지 않는다면 굳이 새로운 Class와 Interface를 만들면서 구현할 필요가 없고 오히려 복잡성이 올라가는 문제가 발생할 것 입니다.

2. 참고 자료

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Design%20Pattern/Strategy%20Pattern.md

GitHub - gyoogle/tech-interview-for-developer: 👶🏻 신입 개발자 전공 지식 & 기술 면접 백과사전 📖

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

전략 패턴

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%A0%84%EB%9E%B5Strategy-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

💠 전략(Strategy) 패턴 - 완벽 마스터하기

https://victorydntmd.tistory.com/292

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

https://joel-dev.site/75

저는 전략 패턴이 처음이라니까요?

https://jinioh88.tistory.com/71

[개발이야기 - 디자인패턴] 전략패턴(Strategy pattern)