캡슐화가 우선
사용자가 상태를 몰라도 되는 API가 중요하면 상태 객체 방식이 읽기 쉽습니다.
같은 블로그 게시 흐름이라도 “상태 객체로 캡슐화할지”, “타입으로 전환을 고정할지”에 따라 얻는 안정성과 유연성이 달라집니다.
외부 코드는 `Post` 하나만 다루며, 상태별 규칙은 각 객체 안에 모입니다.
잘못된 호출을 “빈 문자열 반환”처럼 런타임 동작으로 처리합니다.
새 상태를 추가하면 인접 상태의 전환 메서드를 함께 손볼 수 있습니다.
`content`가 없는 타입에서는 해당 메서드 호출 자체가 컴파일되지 않습니다.
호출자는 `let post = ...` 섀도잉처럼 상태 전환을 코드에 드러냅니다.
전환 경로가 반환 타입으로 보이므로 API 문서와 컴파일러가 같이 돕습니다.
사용자가 상태를 몰라도 되는 API가 중요하면 상태 객체 방식이 읽기 쉽습니다.
유효하지 않은 상태를 아예 만들 수 없게 하려면 타입 상태가 강합니다.
“런타임 규칙인가, 타입으로 표현할 규칙인가?”를 먼저 나누면 설계가 선명해집니다.