[Design Pattern] State Pattern - 상태 패턴

State Pattern

상태 패턴(State Pattern)은 객체가 내부 상태에 따라 행동을 다르게 할 수 있게 해주는 디자인 패턴입니다.

• 객체는 상태를 변경함으로써 행동이 바뀝니다.
• 상태 패턴을 사용하면 조건문을 많이 사용하는 코드를 간결하고 확장 가능하게 만들 수 있습니다.
• State는 상태 = 사물의 모양이나 형편을 의미합니다.
• 또한 상태를 클래스로 표현하면 클래스를 교체해서 '상태의 변화'를 표현할 수 있습니다.
• Strategy Pattern과 조금 유사합니다.

 

 

우리가 만들고자 하는 Object에 상태가 있다면 사용할 수 있는 Pattern 입니다.

 

• 상태를 가지는 가장 대표적인 예가 신호등 입니다.
• 녹색, 빨강색 중 하나의 상태만 가지는 기계이며, 계속해서 상태가 변화됩니다.

---

State Pattern을 사용하지 않은 코드

class TrafficLight:
    def __init__(self):
        self.state = 'green'

    def setState(self, state: str):
        self.state = state

    def speak(self):
        if self.state == 'green':
            print('green light')
        elif self.state == 'red':
            print('red light')

    def wait(self):
        print('wait.. the light changed')
        if self.state == 'green':
            self.state = 'red'
        elif self.state == 'red':
            self.state = 'green'

 

• __init__
  • 기본 state는 'green'으로 설정합니다.
• setState
  • 현재 state를 설정할 수 있는 함수입니다.
• speak
  • 현재 state에 따라 'green light' 또는 'red light'를 출력합니다.
• wait
  • 호출 시 state가 변경되며, 'wait.. the light changed'를 출력합니다.

 

# 예제 사용
t_light = TrafficLight()
t_light.speak()   # 출력: green light
t_light.wait()    # 출력: wait.. the light changed
t_light.speak()   # 출력: red light

 

• TrafficLight 객체인 t_light 을 생성합니다.
• speak() 호출 시 현재 state는 green이므로 'green light' 가 출력됩니다.
• wait() 호출 시 state가 red로 변경되며 'wait.. the light changed' 가 출력됩니다.
• speak() 호출 시 state는 red이므로 'red light' 가 출력됩니다.

 

하지만, State가 많아진다면 현재 코드 구조로는 복잡성을 대응하기가 어렵습니다.

이때 State Pattern을 이용할 수 있습니다.

State Pattern 클래스 구조

 

---

TrafficLight Class

class TrafficLight:
    def __init__(self):
        self.state = GreenLight()

    def setState(self, state):
        self.state = state

    def speak(self):
        self.state.status()

    def wait(self):
        self.state.changeLight(self)

 

 

TrafficLight 클래스

• 기본 상태로 GreenLight 객체를 가집니다.
• setState 메서드를 통해 상태를 변경할 수 있습니다.
• speak 메서드를 호출하면 현재 상태 객체의 status 메서드를 호출하여 상태를 출력합니다.
• wait 메서드를 호출하면 현재 상태 객체의 changeLight 메서드를 호출하여 상태를 변경합니다.

 

State 클래스 및 구체적인 상태 클래스

class State:
    def status(self):
        pass

    def changeLight(self, traffic_light: TrafficLight):
        pass

class GreenLight(State):
    def status(self):
        print('green light')

    def changeLight(self, traffic_light: TrafficLight):
        print('wait.. the light changed')
        traffic_light.setState(RedLight())

class RedLight(State):
    def status(self):
        print('red light')

    def changeLight(self, traffic_light: TrafficLight):
        print('wait.. the light changed')
        traffic_light.setState(GreenLight())

 

 

 

• State 클래스
  • 상태 객체들이 상속받는 추상 클래스입니다.
  • status 메서드는 현재 상태를 출력합니다.
  • changeLight 메서드는 상태를 변경합니다.
• GreenLight 클래스
  • State 클래스를 상속받아 구현된 클래스입니다.
  • status 메서드는 "green light"를 출력합니다.
  • changeLight 메서드는 TrafficLight 객체의 상태를 RedLight로 변경합니다.
• RedLight 클래스
  • State 클래스를 상속받아 구현된 클래스입니다.
  • status 메서드는 "red light"를 출력합니다.
  • changeLight 메서드는 TrafficLight 객체의 상태를 GreenLight로 변경합니다.

 

t_light = TrafficLight()
t_light.speak()   # 출력: green light
t_light.wait()    # 출력: wait.. the light changed
t_light.speak()   # 출력: red light

• 동작 예시
  • t_light 객체를 생성하고 speak 메서드를 호출하면 현재 상태인 "green light"가 출력됩니다.
  • wait 메서드를 호출하면 상태가 RedLight로 변경되고 "wait.. the light changed"가 출력됩니다.
  • 다시 speak 메서드를 호출하면 현재 상태인 "red light"가 출력됩니다.

---

개념 확장

Divide and Conquer

• 주어진 문제를 작은 문제들로 나누어야 합니다.
• 각각의 구체적인 상태를 각각의 클래스로 표현해서 문제를 분할한 것입니다.
• State 패턴을 사용하지 않으면 상태가 많으면 많을수록 조건 분기도 증가합니다.
• 비슷한 조건분기를 사건이 발생할 때마다 호출되는 메소드에 전부 기술해 주어야 합니다.
• State 패턴은 시스템의 상태를 클래스로 표현해서 복잡한 프로그램을 분할하고 있습니다.

 

State의 전환은 누가 관리해야 하는가?

• 상태를 클래스로 표현해서 ConcreteState 역할에 분담하는 것은 좋은 방법입니다.
• 그러나 State 패턴을 사용할 경우 상태 전환은 누가 관리해야 하는지 생각해 봐야 합니다.
• Context 역할의 Traffic Light가 상태 전환을 실제로 수행하도록 setState를 구현하였습니다.
• 그러나 setState를 실제로 호출하는 것은 ConcreteState 역할의 GreenLight 또는 RedLight 클래스입니다.
• 즉, 상태 전환을 상태에 의존한 동작으로 간주되고 있는데, 이것은 장단점이 있습니다.
  • 장점: 다른 상태로 전환하는 것에 대한 정보가 하나의 클래스 내에 정리되어 있고, 가령 GreenLight 클래스가 어떤 상태로 전환하는지는 GreenLight 클래스 코드만 읽으면 됩니다.
  • 단점: 하나의 ConcreteState 역할이 다른 ConcreteState 역할을 서로 알아야 한다는 것입니다. 이것은 만약 하나를 삭제하고 싶으면 의존된 또 다른 것도 수정해야 한다는 것을 의미합니다.
• 상태 전환을 ConcreteState에게 맡기면 클래스 사이의 의존관계가 깊어집니다.

 

Context 역할에게 상태 전환의 업무를 맡기면 되지 않는가?

• 그렇게 되면 각각의 ConcreteState 역할의 독립성이 높아지는 것은 좋습니다.
• 그러나 이번에는 Context 역할이 모든 ConcreteState 역할을 알아야 하는 문제가 발생합니다.