我在我的应用程序中使用了 28 个州的状态模式，这些州适用于有 7 个主要州的会员卡，会员卡有 4 个布尔属性实际上会影响其行为，所以我决定将它们嵌入到状态中，那就是它是如何增加到 28 个州的。
现在的问题是状态类命名，它变得越来越疯狂，我最终得到了这样的类状态 Membership-UnderCreation-Printed-Linked-Premium-Frozen -----我用连字符连接了不同的属性以使其清楚。
状态类名可以这样吗？！我应该怎么做才能获得最佳实践？
问问题
109 次
2 回答
0
正如 plalx 所说，就目前而言，该设计不易维护。正如 plalx 建议的那样，您应该只有 7 个主要状态。
对于其他 4 个属性，一种选择是使用装饰器设计模式。4 个属性中的每一个都可以设计为 4 个装饰器类。根据设置的属性，相应的装饰器对象将包装原始对象。然后装饰器可以拦截来自客户端的调用并根据该装饰器的属性修改行为。
于 2013-09-10T04:30:21.433 回答
0
也许你把它推得太远了。我认为您当前的方法是不可维护的，并且取决于这一切将如何演变，它可能导致不同状态的爆炸式增长。
关于如何解决这个问题，我有一些想法。您可以使用状态模式实现 7 个主要状态并使用标志来跟踪其他条件，因此在每个状态中您都可以基于这些编写条件语句。函数中的代码会变得稍微复杂一些，但我相信它仍然更易于维护。
我没有太多关于您的状态转换和所有内容的信息，但另一个想法是拥有一个状态类，您可以通过传入激活状态所需满足的条件集合从中创建匿名子类。
然后，您不必命名任何状态，只需将它们保存在一个集合中，当主对象的任何属性更改可能导致状态更改时，您遍历状态集合，您将找到新的通过将对象属性与状态条件进行比较来确定状态。
请注意，您还可以使用 HashMap 来存储状态并根据所有条件创建哈希以获取唯一键。这将使状态查找比遍历所有状态查找下一个状态更快。
于 2013-09-07T19:25:03.947 回答