상태 패턴이란, 특정 상태에 따라 행동을 달리하는 상황에서는 조건문을 사용해서 구현했는데, 이 대신에 상태를 객체화해서 그 상태가 행동을 하도록 위임하는 행동 패턴이다.
즉, 상황에 따른 기능을 State 객체에 정의하고 이 상황을 객체화한 후, 상황에 따른 기능을 사용해야하는 개체가 State 객체를 소유하도록 구현.
State를 갈아끼면서 수행

구조

• State 인터페이스 : 상태를 담당하는 최상위 객체
• ConcreteState : State를 상속받은 하위 State 객체
  • 상태클래스는 싱글톤으로 구성한다.
  • 기능을 담당하기 때문에 가능
• Context : State를 사용해야 하는 시스템
  • State(상황)을 소유

예시 코드

State 인터페이스, 클래스 구현

interface AbstractState {
    void requestHandle(Context cxt);
}

class ConcreteStateA implements AbstractState {
    @Override
    public void requestHandle(Context cxt) {}
}

class ConcreteStateB implements AbstractState {
    @Override
    public void requestHandle(Context cxt) {
        // 상태에서 동작을 실행한 후 바로 다른 상태로 바꾸기도 함
        // 예를 들어 전원 on 상태에서 끄기 동작을 실행한후 객체 상태를 전원 off로 변경 하듯이
        cxt.setState(ConcreteStateC.getInstance());
    }
}

class ConcreteStateC implements AbstractState {
    @Override
    public void requestHandle(Context cxt) {}
}

Context 클래스 구현

class Context {
    AbstractState state; // composition

    void setState(AbstractState state) {
        this.state = state;
    }

    // 상태에 의존한 처리 메소드로서 state 객체에 처리를 위임함
    void request() {
        state.requestHandle(this);
    }
}

main 문

class Client {
    public static void main(String[] args) {
        Context context = new Context();

        // 1. StateA 상태 설정
        context.setState(new ConcreteStateA());

        // 2. 현재 StateA 상태에 맞는 메소드 실행
        context.request();

        // 3. StateB 상태 설정
        context.setState(new ConcreteStateB());

        // 4. StateB 상태에서 또다른 StateC 상태로 변경
        context.request();

        // 5. StateC 상태에 맞는 메소드 실행
        context.request();
    }
}

사용 시기

• 객체의 메서드가 상태에 따라 다른 동작할때
• 조건 분기 코드가 많고 중복되는 코드가 많을떄
• 런타임 단에서 객체를 유연하게 변경

장점

• 상태에 따른 동작을 클래스로 관리 가능
• 많은 분기문과 중복되는 코드 제거
• 상태를 담당하는 별도의 클래스로 단일 책임 원칙 준수
• 다른 상태를 추가하는데에 유연 -> 개방 폐쇄 원칙 준수

단점

• 관리해야할 클래스 추가
• 상태에 따른 규칙이 자주 바뀌면 복잡도 올라감
• 상태의 가지수가 많이 않다면 패턴을 적용하는 것이 오히려 역효과