如果没有代码：它只是一个智力挑战还是具体有用？

Question

我的一位朋友正在讨论关于对象的状态转换的这些设计技术（他是一个Java大师，顺便说一句），没有boolean myState成员执行，而是将myState成员声明为实现“所有者”的相同接口的对象。

好的，我太神秘了，所以你可以通过代码示例找到讨论here。

就个人而言，我对这种方法很兴奋，因为我的朋友向我解释了背后的哲学;从设计的角度来看，我也认为它非常连贯。顺便说一句，我关心的是性能和内存使用情况，因为编译时和运行时优化可能会进入游戏。由于我不了解JIT编译器和JVM内部，我很想得到更广泛的意见。

你怎么看？

Answer 1

我不同意 - 除了有用的设计模式，这个特殊的例子是荒谬的过度杀伤：

• 15行课程，具有易于理解的过程
• 成为一个具有混淆目的的50行课程

我没有看到这是一个改进 - 它违反了YAGNI ¹ 和ASAP ² ，使代码膨胀，并降低了效率（多个对象被实例化以完成工作如果不需要）。

作为一项智力练习，有点有趣。作为编程习惯，可怕！ ;-)

<小时/> ¹ YANGI =你不需要它

² ASAP =尽可能简单

Answer 2

听起来你问的是，使用状态设计模式是否有“具体有用”的好处，我肯定会说是肯定的，特别是如果你的应用程序实际上很大程度上依赖于其对象的“状态”。一个流行的规范示例是视频播放器，它总是处于一种状态，并且只能根据它当前所处的状态转换到不同的状态（例如，如果它已经停止但是它可以播放它不能停止，它可以倒带，等等）。

虽然可以使用少数if / else / switch类型条件（if（isStopped（）），play（）等）相对容易地管理该特定示例，因为没有那么多状态可以处理当状态或其转换规则开始变得更多或更复杂时，状态模式绝对变得非常有价值，因为没有它，你的代码往往会像疯了一样积累其他东西，随着时间的推移，事情变得越来越不易读和可管理。

所以是的，一般来说，如果你发现你的对象的行为根据它们的状态而变化（如果isStopped（）play（）/ elseif isPlaying（）stop（）/ elseif（isBroken（）fix（））等等。 ），然后是的，请考虑使用状态模式。这是一个更多的工作，但通常非常值得努力，并做得正确我怀疑你会发现任何显着的开销只是为了使用它。

Head First Design Patterns也很好地描述了它的方法和原因 - 我强烈建议将这本书提供给几乎任何编写面向对象代码的人。

Answer 3

状态/策略模式经过验证并且是真实的。它们不仅仅是一种智力锻炼。如果你现在正在考虑性能和内存使用情况......你可能会在自己的脚下开枪。获取代码......然后是个人资料。

Answer 4

这是一项非常有用的技术。

你不会在你的班级传播if（myState）语句 您可以将技术扩展到许多州，只需要更改分配给 myState 成员的内容。

至于性能和内存使用情况，请等到你有一些东西要测量 - 也许你需要尝试两种方法并在它们工作时测量它们。

Answer 5

是的，这很有效，而且很酷......直到某一点（它变得愚蠢的地方）。你甚至可以使用匿名内部类，甚至枚举。