디자인 패턴은 몇가지로 분류된다. 생성,구조,행위 의 3가지가 그것인데 특히 행위(behaviord) 패턴에 속하는 패턴들은 객체들 사이의 관계를 통해 어떤 결과가 일어나는지에 초점이 맞춰져 있다. State 패턴도 그 중 하나이다. State 패턴은 이름 그대로 “상태”를 객체로 표현하는 것이 목적이다. 하지만 중요한 것은 “왜 상태를 상수가 아닌 굳이 객체로 정의하는가”에 대한 것과 “이렇게 정의 된 상태는 어떻게 사용되는가”정도가 될 것이다.
State 패턴의 내용을 간략하게 정리해보자.
1. Client 는 context와 작업한다.
2.context 내부에서는 언제나 동일한 개념으로 State 인스턴스를 다룬다. (ex: state :: Open ( ) 호출 등)
3. context 내부에서 관리되는 State의 인스턴스가 상황에 맞게 교체되기 때문에 open 메서드의 동작결과는 바뀌게 된다.
이런 State의 동작원칙 덕분에 context 객체의 내부에서는 메세지를 다루는 작업에 대한 일관성을 확보하게 된다.
State 클래스의 추상클래스화를 통한 State의 다양한 상태를 수평적으로 늘일 수 있다. State가 표현해야 하는 각 상태를 상수로 정의하면 context 객체 내부에는 상수값을 판별해서 동작하는 내부조직이 직접 구현되어 있어야만 한다.
하지만 State 객체를 쓰면 상태에 따른 동작을 State 클래스군에서 책임지기 때문에 상태별 동작에 따른 코드를 새로운 Context 마다 복사해서 사용하는 대신에, 재사용을 쉽게하며 상태별 동작에 대한 코드의 유지보수를 보다 쉽게 할 수 있다. State의 하위 인스턴스는 그 자체로 상태의 타입을 의미하기 때문에 State의 인스턴스에게 동적인 리소스를 가지고 있게 구조를 만드는 것은 피하도록 하다. Context인스턴스 내부에서 관리되는 State 변수의 인스턴스 교환/관리는 context의 몫이지만 State 클래스군에 상태별 규칙을 넣어 State의 하위 클래스들간에 서로 상호작용하며 반응하게 할 수 있다면 보다 좋은 구현이 될 것이다.