같은 요청에도 현재 조건에 따라 행동과 다음 상태가 달라지는 로직을, 값·조건문 대신 독립된 상태 객체로 모델링하는 State 패턴을 개발자·블랙잭 예제로 설명한다. 패턴이 언제 도메인을 자연스럽게 하고 언제 과한 비용이 되는지를 함께 짚는 균형 잡힌 소개다.
핵심 포인트- 상태가 둘뿐이면 enum + if가 더 단순할 수 있지만, State 패턴에서는 각 상태가 자기 행동과 다음 상태를 반환하고 컨텍스트는 분기 없이 요청을 위임
- 조건문 방식은 상태가 하나 늘 때마다 인사·야근·급여처럼 상태를 검사하는 모든 메서드에 분기를 추가해야 하는 반면, 상태 객체 방식은 새 클래스와 필요한 전이 지점만 연결
- 블랙잭 예에서 Bust·Blackjack을 여러 객체가 반복해 묻고 조건문으로 승패·카드 수령을 조합하던 흩어진 로직을, Hit·Stay·Bust·Blackjack 상태 객체로 손패·종료·수익 계산 책임을 옮겨 정리
- 다만 상태가 적고 변화가 드문 곳에서는 클래스 증가와 학습 비용이 단순한 조건문보다 불리할 수 있다는 트레이드오프를 명시
왜 읽나분기가 여기저기 흩어진 상태 로직에 골머리를 앓는 개발자에게, State 패턴의 효용과 그 도입 비용을 함께 판단하게 해주는 실전 가이드.