State Pattern

State Pattern

OOP에서는 프로그램 대상을 클래스로 표현함

 

state는 '상태 = 사물의 모양이나 형편'을 의미

상태를 클래스로 표현하면 클래스를 교체해서 '상태의 변화'를 표현할 수 있음

Strategy Pattern과 조금 유사함

__ init __

property로 state (기본 state는 'green')

 

setState

현재 state를 설정할 수 있는 함수

 

Speak

State에 따라서 녹색이면 green light

빨강이면 red light 출력

 

Wait

Wait 함수를 호출하면 state가 변함

 

 

 

 

 

 

 

 

 

 

 

하지만 state가 많아진다면 현재 코드 구조로는 복잡성을 대응하기 어려움

-> 이때 state pattern 사용가능

TrafficLight class

 

__ init __

기본 state로 GreenLight 가짐

 

setState

argument로 받은 state 변경

 

Speak

현재 상태 object의 speak 함수인 status() 호출

초록 불이라면 greenLlight class의 status() 호출

빨강 불이라면 redLight class의 status() 호출

 

Wait

speak와 마찬가지로 현재 상태 object의 wait 함수인 changeLight() 호출

 

 

status

현재 상태 출력

 

changeLight

argument로 받은 state로 변경

 

 

 

 

 

GreenLight, RedLight

State class를 상속받음

 

status

자신의 상태 출력

 

changeLight

상태 변경해주는 함수

TrafficLight 의 setState를 통해서 상태 변경해야됨

TrafficLight의 setState를 호출하기 위해서는 argument로 TrafficLight을 받아야함

 

 

 

 

---

개념 확장

 

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

상태를 클래스로 표현해서 ConcreteState 역할에 분담하는 것은 좋은 방법임

그러나 State 패턴을 사용할 경우 상태 전환은 누가 관리해야하는 지 생각해봐야함

 

Context 역할은 Traffic Light가 상태전환을 실제로 수행하도록 setState를 구현하였음

그러나 setState를 실제로 호출하는 것은 ConcreteState 역할의 GreenLight또는 RedLight 클래스임

즉, 상태전환을 상태에 의존한 동작으로 간주되고 있는데 이것은 장단점이 있음

 

장점 : 다른 상태로 전환하는 것에 대한 정보가 하나의 클래스 내에 정리되어 있고, 

가령 GreenLight 클래스가 어떤 상태로 전환하는 지는 GreenLight 클래스의 코드만 읽으면 됨

 

단점 : 하나의 ConcreteState 역할이 다른 ConcreteState 역할을 서로 알아야한다는 것임

이것은 만약 하나를 삭제하고 싶으면 의존된 또 다른 것도 수정해야한다는 것을 의미함

 

-> 상태전환을 Concrete 에게 맡기면 클래스 사이의 의존관계가 깊어짐

 

---

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

- 그렇게 되면 각각의 ConcreteState 역할의 독립성이 높아지는 것은 좋음

- 그러나 이번에는 Context역할이 모든 ConcreteState 역할을 알아야하는 문제가 발생함.