【问题标题】:state pattern long state class names状态模式长状态类名
【发布时间】:2013-09-07 18:48:55
【问题描述】:

我在我的应用程序中使用了 28 个州的状态模式,这些州适用于有 7 个主要州的会员卡,会员卡有 4 个布尔属性实际上会影响其行为,所以我决定将它们嵌入州,这就是它如何乘以 28 个州。

现在的问题是状态类命名,它变得越来越疯狂,我最终得到了这样命名的类状态 Membership-UnderCreation-Printed-Linked-Premium-Frozen -----我用连字符连接了不同的属性以使其清楚。

状态类名可以这样吗?!我应该怎么做才能获得最佳实践?

【问题讨论】:

  • 如果你有 4 个布尔属性,那不应该转化为 16 个状态吗?可能你的意思是一次只能设置一个属性,如果是这样,那么这些属性不是独立的。

标签: design-patterns state-pattern


【解决方案1】:

也许你把它推得太远了。我不认为您当前的方法是可维护的,并且取决于这一切将如何演变,它可能会导致不同状态的爆炸式增长。

我对如何解决这个问题有一些想法。您可以使用状态模式实现 7 个主要状态并使用标志来跟踪其他条件,因此在每个状态中您都可以基于这些编写条件语句。函数中的代码会稍微复杂一些,但我相信它仍然更易于维护。

我没有太多关于你的状态转换和一切的信息,但另一个想法是有一个单一的状态类,你可以通过传入一组需要满足的条件来创建 anonymous subclasses 以激活状态。

然后,您不必命名任何状态,只需将它们保存在一个集合中,当主对象的任何属性更改可能导致状态更改时,您循环遍历状态集合并按照您的意愿通过将对象属性与状态条件进行比较来找到您的新状态。

请注意,您还可以使用 HashMap 来存储状态并根据所有条件创建散列以获取唯一键。这将使状态查找比遍历所有状态查找下一个状态更快。

【讨论】:

  • 我已经想到了第一个解决方案,但不想破坏模式,这就是我努力让它完全正确的原因:(
  • 嗯,有时它就是不合适。您想要实现它的方式根本无法维护。你对我的第二个解决方案(使用匿名类)有意见吗?这肯定比为每个排列创建一个具体的类更好。
  • 我不确定我是否得到你的第二个解决方案,可能是因为我对匿名类不太了解,我使用的是 c# btw,它支持匿名类吗?
  • @user2080257,嗯,我查了一下,C# 中没有类似匿名类的东西,但是你可以看看stackoverflow.com/questions/4770180/…
【解决方案2】:

正如 plalx 所说,就目前而言,该设计不易维护。正如 plalx 建议的那样,您应该只有 7 个主要状态。

对于其他 4 个属性,一种选择是使用装饰器设计模式。 4 个属性中的每一个都可以设计为 4 个装饰器类。根据设置的属性,相应的装饰器对象将包装原始对象。然后装饰器可以拦截来自客户端的调用并根据该装饰器的属性修改行为。

【讨论】:

  • 我已经检查了装饰器模式,但看起来它是可用的,扩展类中的方法必须包含其基方法在具体类中的完整行为作为它的一部分,情况并非如此,我在大多数情况下都在谈论每种方法的完全不同的行为。我说对了吗?
  • 我不认为装饰器模式在这里可以很好地工作,因为它是定义行为的多个状态的组合,这意味着装饰器需要了解其他状态才能定义自己的行为。
  • @user2080257 你是对的。如果每种方法都不同,那么装饰器模式就不合适了。如果 23 个州的大多数方法都不同,那么您就几乎无法改进当前的设计。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-02-01
  • 2017-01-05
  • 1970-01-01
  • 1970-01-01
  • 2011-12-14
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多