[디자인 패턴] - State

State

객체의 내부 상태에 따라 객체의 행동이 바뀌도록 설계하는 패턴.
즉, 상태가 바뀌면 객체의 행위(메서드 결과)도 달라진다.

마치 if-else나 switch 문으로 상태별 행동을 구현하는 대신, 상태를 클래스로 추출해서 각 상태마다 행동을 정의한다.

예시 코드

// 상태 인터페이스
interface State {
    void handle();
}
 
// 구체적인 상태
class OnState implements State {
    public void handle() {
        System.out.println("전원이 켜졌습니다.");
    }
}
 
class OffState implements State {
    public void handle() {
        System.out.println("전원이 꺼졌습니다.");
    }
}
 
// Context (상태를 갖는 객체)
class PowerSwitch {
    private State state;
 
    public PowerSwitch(State state) {
        this.state = state;
    }
 
    public void setState(State state) {
        this.state = state;
    }
 
    public void pressButton() {
        state.handle();
    }
}
 
// 사용 예시
public class StatePatternExample {
    public static void main(String[] args) {
        PowerSwitch power = new PowerSwitch(new OffState());
 
        power.pressButton(); // 꺼진 상태
        power.setState(new OnState());
        power.pressButton(); // 켜진 상태
    }
}

State 패턴의 장점

코드가 깔끔해짐

if-else나 switch문 없이 상태 전환을 객체로 분리 가능하다.

상태 전환이 명확해짐

각 상태 객체가 다음 상태를 직접 관리하므로 전환이 자연스럽다.

단일 책임 원칙(SRP)

각 상태 클래스가 자신이 해야 할 일을 독립적으로 관리한다.

확장성

새로운 상태를 추가해도 기존 코드 수정이 거의 없다.

State 패턴의 단점

상태 클래스가 많아짐

상태가 많을수록 클래스 파일이 많아짐 (복잡도 ↑)

상태 관리 어려움

상태 간의 전환 흐름이 복잡해지면 설계가 까다로워짐

설정 비용

작은 상태 변화에는 과한 패턴일 수 있음

State 패턴은 언제 사용하나?

객체가 다양한 상태에 따라 행동이 바뀔 때

ex) 문 상태 (열림/닫힘/잠김), 게임 캐릭터 상태 (대기/공격/피격 등)

if-else/switch가 너무 많을 때

ex) 상태별 처리 코드가 길어져서 유지보수가 어려운 경우

UI/UX 상태 흐름 관리

버튼 상태, 입력창 활성/비활성 등 GUI 컨트롤 관리 시

정리하자면

State 패턴은 객체의 상태를 캡슐화하여, 상태에 따른 동작을 클래스 수준에서 분리하고,
상태 전환과 행동 변경을 유연하게 처리할 수 있도록 도와주는 디자인 패턴이다.