개념
•
상태 패턴은 특정 상태에 따라 객체의 동작이 달라지는 상황에서 상태를 객체화하여 상태에게 동작을 위임하는 패턴이다.
•
상태를 클래스로 표현하면 클래스를 교체해서 상태가 변화됨을 표현할 수 있고 객체 내부 상태 변경에 따라 객체의 동작을 상태에 특화된 동작으로 분리해낼 수 있다.
◦
새로운 상태를 추가하면 새로운 동작이 추가되는 것!
•
객체가 특정 상태에 따라 동작이 달라질 때 사용되기에 가장 적합한 패턴이다.
전략 패턴이 전략 알고리즘을 클래스로 표현한 패턴이라면 상태 패턴은 객체 상태를 클래스로 표현한 패턴이라고 보면 된다.
구조
•
State
◦
인터페이스로 상태를 추상화한 고수준 모듈이다.
◦
Context가 의존한다.
•
Context
◦
State를 이용하는 시스템이다.
◦
시스템 상태를 나타내는 State 객체를 합성하여 가지고 있다. 클라이언트로 받은 요청 처리의 책임을 State 구상 객체에게 위임한다.
•
ConcreteState
◦
구체적인 각 상태를 클래스로 표현한 것이다. State 역할로 결정되는 인터페이스를 구현한다.
◦
Context에서 처리를 위임받아 직접 동작을 수행하기도 한다.
특징
•
목적
◦
객체의 메소드가 상태에 따라 각기 다른 동작을 수행해야 할 때
◦
상태 및 전환에 걸쳐 대규모 조건 분기 코드와 중복 코드가 많은 경우
▪
조건문의 각 분기를 별도의 클래스에 넣는 것이 상태 패턴의 핵심이다.
◦
런타임단에서 객체의 상태를 유동적으로 변경해야 할 때
•
장점
◦
상태에 따른 동작을 개별 클래스로 옮겨서 관리할 수 있다.
◦
상태와 관련된 모든 동작을 각각의 상태 클래스에 분산시킴으로써 코드 복잡도를 줄일 수 있다.
◦
SRP, OCP 원칙을 준수할 수 있다.
◦
하나의 상태 객체만 사용하므로 일관성 없는 상태 주입을 방지하는데 도움이 된다.
•
단점
◦
상태 별로 클래스를 생성해야하므로 클래스 수가 늘어난다.
◦
상태 클래스 갯수가 많고 상태 규칙이 자주 변경된다면 상태 인터페이스를 사용하는 코드가 복잡해질 수 있다.
◦
객체에 적용할 상태가 몇가지 밖에 없거나 거의 상태 변경이 발생하지 않는 경우는 패턴 적용이 오버헤드일 수 있다.
