我的一个朋友正在谈论这些关于对象状态转换的设计技术（顺便说一句，他是 Java 大师），在没有 boolean myState 成员的情况下执行，而是将 myState 成员声明为实现的对象与“所有者”的界面相同。
好的，我太神秘了，所以你可以找到讨论here，带有代码示例。
就我个人而言，我对这种方法感到很兴奋，因为我的朋友向我解释了它背后的理念；从设计的角度来看，我也认为它非常连贯。顺便说一句，我关心的主要是性能和内存使用，因为编译时和运行时优化可能会进入游戏。由于我不了解 JIT 编译器和 JVM 内部结构，我很想有更广泛的意见。
你怎么看？
【问题讨论】：
标签： java design-patterns oop
我不得不不同意 - 除了有用的设计模式，这个特殊的例子是荒谬的矫枉过正：
我看不出这是一种改进——它违反了 YAGNI1 和 ASAP2，使代码膨胀，并降低了效率（实例化了多个对象来完成这项工作不需要时）。
作为一种智力练习，有点意思。作为一种编程习惯，可怕！ ;-)
2 ASAP = 尽可能简单
【讨论】：
听起来您在问使用状态设计模式是否有“具体有用”的好处，我肯定会说是的，特别是如果您的应用实际上严重依赖其对象的“状态”。一个流行的典型示例是视频播放器，它始终处于一种状态，并且只能根据当前所处的状态转换为不同的状态（例如，如果它已经停止，它就不能停止，但它可以播放，它可以倒带，等等）。
虽然该特定示例可以通过一些 if/else/switch 类型的条件（if (isStopped())、play() 等）相对轻松地进行管理，因为没有那么多状态需要处理，当状态或它们的转换规则开始变得更多或更复杂时，状态模式绝对变得非常有价值，因为没有它，您的代码往往会疯狂地积累 elseif，随着时间的推移，事情变得越来越难以阅读和管理。
所以是的，一般来说，如果您发现对象的行为根据它们的状态而变化（if isStopped() play() / elseif isPlaying() stop() / elseif (isBroken() fix()) 等。 )，那么是的，请考虑使用 State 模式。前面的工作要多一些，但总的来说值得付出努力，而且做得对，我怀疑你会注意到仅仅因为使用它而产生的任何重大开销。
Head First Design Patterns 也很好地描述了它的方法和原因——我强烈建议几乎所有编写面向对象代码的人都可以阅读这本书。
【讨论】：
状态/策略模式是经过验证的。它们不仅仅是智力活动。如果您现在正在考虑性能和内存使用情况……您可能正在自找麻烦。获取代码...然后配置文件。
【讨论】：
这是一种非常有用的技术。
您不会在您的班级周围传播 if(myState) 语句。
您可以将该技术扩展到许多状态，并且只需更改您分配给 myState 成员的内容。
至于性能和内存使用情况，等到你有东西要测量——也许你需要尝试两种方法，并在它们工作时测量它们。
【讨论】：
是的，这很有效，而且很酷......直到某个点（它变得愚蠢的点）。如果必须，您甚至可以使用匿名内部类，甚至可以使用枚举。
【讨论】：