我在我的应用程序中使用28状态的状态模式，状态是有7个主要状态的会员卡，会员卡有4个布尔属性实际影响其行为，所以我决定嵌入它们这就是它如何成倍增加到28个州。
现在的问题是状态类命名，它变得越来越疯狂，我最终得到了像这样命名的类状态 会员资格 - UnderCreation-Printed-Linked-Premium-Frozen -----我已经用不同的属性来澄清它。
状态类名称可以这样吗？！我应该怎样做才能获得最佳实践？
答案 0 :(得分：0)
也许你推得太远了。我不认为你目前的方法是可维护的，并且取决于所有这些方法将如何发展，它可能导致不同状态的爆炸。
我对如何解决这个问题有一些想法。您可以使用状态模式实现7个主要状态，并使用标志来跟踪其他条件，因此在每个状态中，您可以根据这些状态编写条件语句。函数中的代码会变得更加复杂，但我相信它仍然会更易于维护。
我没有太多关于你的状态转换和所有内容的信息，但另一个想法是有一个状态类，你可以通过传递一系列需要满足的条件来创建anonymous subclasses激活状态。
然后，您不必为任何状态命名，只需将它们保存在集合中，当主对象的任何属性发生更改时可能导致状态更改时，您将遍历状态集合和您的意愿通过比较对象属性和状态条件来找到新状态。
请注意，您还可以使用HashMap存储状态并从所有条件创建哈希以获取唯一键。这将使状态查找比遍历所有查找更快，以找到下一个状态。
答案 1 :(得分：0)
正如plalx评论的那样，设计并不容易维护。正如plalx所暗示的，你应该只有7个主要状态。
对于其他4个属性，一个选项是使用装饰器设计模式。 4个属性中的每一个都可以设计为4个装饰器类。根据设置的属性，相应的装饰器对象将包装原始对象。然后，装饰器可以拦截来自客户端的调用，并根据该装饰器的属性修改行为。