design-patterns - 状态机适合处理促销系统中的状态变化吗？

Question

我正在开发促销系统，我刚刚踩到了一些可能可以用状态机模式处理的东西，但我还没有状态机的经验。也许状态机在这种情况下完全没用:)所以我有一个促销事件，它有一定的持续时间，一些指定的客户，产品，折扣等。每个促销事件也有它的状态。大约有5个州。状态之间的转换是严格定义的 - 不可能直接将状态 1 更改为状态 3 - 用户必须首先将状态更改为状态 2。有一些限制，例如“促销处于状态 3-5 时无法添加更多产品”。或者诸如“只有 super 用户才能在状态 3-5 时编辑促销费用”之类的限制。

我刚刚读到 http://www.codeplex.com/SimpleStateMachine ，但我不确定对于这种情况来说是否太复杂。我可以使用以下方法处理服务层中的状态逻辑:

if (promotion.state == statesRepository.GetState3() && false == loggedUser.IsInRole("superUser")){
   throw new PromotionStateException("user not allowed to edit promotion in this status");
}
...

或

public void ChangePromotionStatus(promotion, newStatus){
  if (promotion.Status == status1 && newStatus != statesRepo.GetState2()){
    throw new StateTransitionException("unable to change from status 1 to " + newStatus);
  }
}

但我不喜欢这种代码 - 必须有更好的方法:) 有人有建议吗？我当然可以分离关注点并开发诸如 PromotionStatusChangeReviewService、PromotionEditPermissionService 等服务来减少代码的耦合，但目前可能有一些更好的解决方案我看不到。

Answer 1

对于状态机来说，五个状态并不太复杂，但我认为通过尝试特殊或显式处理一些转换，您会遇到一些问题。这里有一些提示:

• 除非您能够以有意义的方式标记状态，否则状态机没有任何帮助。 “状态3”没有任何意义；您需要将其命名为有用的名称，例如“Promoted”、“Active”、“Completed”等。

• 状态机模式的一部分假设您有一个独立的实体，它了解状态以及如何在状态之间转换。例如，您不应该在示例中使用像 ChangePromotionStatus() 这样的方法，如果不允许该状态，该方法就会崩溃。状态机应该简单地阻止无法发生的转换。

• 如果可能的转换数量很少且定义明确，并且对它们进行标记是有意义的，那么我还建议对转换进行命名。如果所有转换都执行相同的操作但方式略有不同，这可能特别有用。