这是关于状态机的一般问题，我不需要实际实施方面的帮助。想象一下状态机正式化一个简单的错误报告，从开始到最终消亡。该错误可能会跨越诸如＆＃34; NEW＆＃34;，＆＃34; CONFIRMED＆＃34;，＆＃34;已解决＆＃34;，＆＃34;已重新＆＃34;以及＆＃34;已关闭等状态＃34 ;.除了每个状态转换之外，还有一些附带的验证代码，例如，可以确保在从NEW移动到CONFIRMED时我们已经记录了谁确认了它。
我的问题与初始状态有关 - 当bug只是＆＃34; NEW＆＃34;。很容易说初始验证不是状态机的一部分（例如，确保错误实际上有一些描述，例如，在使用状态＆＃34; NEW＆＃34;在数据库中保存之前） 。但也不是一个状态转换，来自＆＃34;刚创建＆＃34;到＆＃34;新＆＃34;？难道不应该像任何其他过渡一样验证过渡吗？将初始验证与所有其他验证分开是不是人为的和次优的？
另一方面，如果我们确实创造了一个＆＃34;假的＆＃34;初始状态（例如，＆＃34; CREATED＆＃34;），以及它们各自的过渡（＆＃34;创建＆＃34; - ＆gt;＆＃34;新＆＃34;），然后当转换不是＆时会发生什么？ ＃39; t验证？如果它经过验证，那就很好 - 我们切换状态，然后用数据库中的新状态（实际上称为＆＃34; NEW＆＃34; here）保存对象。但是如果它没有验证那么我们显然不想将它保存在数据库中，并且由于没有初始状态和最终状态而破坏状态机模式（我们将有一个初始状态，虽然是假的 - ＆＃34;创建＆＃34; - 但是有两个最终状态 - ＆＃34; CLOSED＆＃34;＆＃34;删除＆＃34;）。不仅如此，还有＃34; DELETED＆＃34; state也是假的，因为永远不会有任何具有该状态的持久对象（就像永远不会有任何具有状态的持久对象＆＃34; CREATED＆＃34;）。
你如何处理这个问题？
答案 0 :(得分：0)
好的，经过进一步调查后，模式看起来确实解决了我自己的问题：在某些（大多数？）状态机模型中，实际上有initial transaction 结束 初始状态。因此，就实际代码而言，实际上存在“假的”初始状态，但该状态不能被视为状态机中的真实状态。