이것은 일반적으로 상태 머신에 관한 질문이므로 실제 구현에 도움이 필요하지 않습니다. 처음부터 끝까지 간단한 버그 리포트를 공식화하는 상태 머신을 상상해보십시오. 이 버그는 "NEW", "CONFIRMED", "RESOLVED", "REOPENED"및 "CLOSED"와 같은 상태로 전환 될 수 있습니다. 모든 상태 전환과 함께 몇 가지 동반 된 유효성 확인 코드가 있습니다. 예를 들어 NEW에서 CONFIRMED로 이동할 때이를 확인한 사람이 기록되어 있는지 확인할 수 있습니다.상태 머신 : 데이터베이스에 초기 저장 전에 유효성 검사?
제 질문은 초기 상태와 관련이 있습니다 - 버그가 단지 "새로운 것"일 때. 초기 유효성 검사가 상태 시스템의 일부가 아니라는 것을 유혹합니다 (예 : 데이터베이스에 상태 "NEW"로 저장하기 전에 버그에 실제로 설명이 있는지 확인). 그러나 "그냥 만든"상태에서 "새로운"상태로 전환하는 것도 아닙니다. 다른 전환과 마찬가지로 전환이 유효해야합니까? 처음 유효성 검사와 다른 유효성 검사를 구분하는 것이 인위적이거나 차선책이 아닌가?
한편 "가짜"초기 상태 (예 : "CREATED")를 해당 전환 ("CREATED"-> "NEW")과 함께 생성하면 전환이 발생할 때 어떤 일이 발생합니까? 유효성이 검사되지 않았습니까? 유효성 검사가 완료되면 상태가 바뀌고 새 상태 (실제로는 "NEW"라고 함)가있는 객체를 데이터베이스에 저장합니다. 그러나 유효성을 검사하지 않으면 분명히 데이터베이스에 저장하고 싶지 않으며 초기 상태와 최종 상태가없는 상태 시스템 패턴을 깨뜨리는 것입니다 (초기 상태는 가짜인데도 불구하고 - "CREATED"-하지만 두 개의 최종 상태 - "CLOSED"및 "DELETED"). 그뿐 아니라 상태가 "CREATED"인 영구 객체가없는 것처럼 "상태가 삭제 된"상태도 가짜 일 수 있습니다.
이 문제는 어떻게 처리합니까? 패턴 자체 내 문제를 해결하는 것처럼
나는 대답했을 것이다. 초기 상태는 첫 번째 "실제"상태를 가리키는 레이블로 볼 수도 있습니다. 항상 전환이있는 것은 아닙니다. 규칙이 매우 엄격하다고 생각하지 않으므로 원하는 경우 유효성 검사를 사용할 수 있습니다. – Fuhrmanator