[헤드퍼스트 디자인패턴] 10. 상태 패턴

상태에 따른 행동의 결과를 다르게 가져가고 싶은 니즈가 있다.이를 위해 아래와 같이 상수를 선언할 수 있다.

final static int SOLD_OUT = 0;
final static int NO_QUARTER = 1;
final static int HAS_QUARTER = 2;
final static int SOLD = 3;

 

이런 식으로 상태를 서술하면 아래와 같은 코드가 필요하다.

으악

 

보기에도 복잡하고, 새로운 상태나 행위가 추가되었을 때 고쳐야할 범위가 굉장히 많아진다.

 

요걸 아래와 같이 '상태를 클래스에 대응'시키는 것으로 리팩토링할 수 있다.

모든 상태는 State 인터페이스를 구현하고, 이 중 하나의 클래스를 살펴보면 아래와 같다.

public class NoQuarterState impletents State {

    GumballMachine gumballMachine;
    
    public NoQuarterState(GumballMachine gumballMachine) {
    	this.gumballMachine = gumballMachine;
    }
    
    public void insertQuarter() {
    	gumballMachine.setState(gumballMachine.getHasQuarterState());
    }
    
    public void ejectQuarter() {}
    
    public void turnCrank() {}
    
    public void dispense() {}
    
}

 

그리고 이걸 GumballMachine 이 아래와 같은 형태로 들고 있는다.

public class GumballMachine {
    State soldOutState;
    State noQuarterState;
    State hasQuarterState;
    State soleState;
    
    ...   
}

 

여기서 나오는 상태 패턴의 장점은 다음과 같다.

상태 패턴을 사용하면, 객체 내부 상태가 바뀜에 따라 객체의 행동을 바꿀 수 있다.
마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있다.

 

(전략 패턴과 다이어그램은 동일하다고 한다. 그러나 용도는 다름!)

 

전략 패턴은 일반적으로 클라이언트가 Context 객체에게 어떤 전략 객체를 사용할지를 지정해준다. 때문에 클라이언트가 어떤 패턴이 사용될지를 알고 있게 된다. 그러나, 상태 패턴의 경우 단순히 Context는 여러 상태 객체 중 한 객체에게 모든 행동을 맡기게 되고, 이때 Context는 어떤 상태인지 전혀 모르게 된다.

 

추가로 아래 사항들을 고려해볼 수 있다.

• State 간 로직이 거의 중복되는 경우 어떻게 처리할 것인가?
  • 하나의 상태로 두면, 중복 로직은 줄어들겠지만 '상태' 라는 관점에서 모호해질 수 있다.
• 특정 상태에서는 호출되어도 별 의미가 없는 메서드를 어떻게 동작하도록 처리할 것인가?
• 현재는 상태 전환 정보가 모두 상태 클래스에 있는데, 이를 Context로 옮기는건 어떤가? 그때의 장단점은 무엇인가?