使用或不使用状态模式？

Question

我正在为一个Uni项目设计弹球游戏，其中应该有两种模式：运行模式和构建器模式，可以设计/重新设计机器的布局。

我最初的想法是状态模式 - 然而，我担心各州之间的共同界面可能会将它们收缩为实施不适合该州的方法。

EG。在构建器模式中，设置保险杠或其他任何位置是完全合适的。但是在运行模式下，它将被实现为什么都不做或抛出异常 - 这看起来很讨厌，特别是如果有很多这样的方法。

这有更好的设计吗？

Answer 1

你的直觉是正确的。当程序可以具有许多不同的状态时，状态模式是有用的，每个状态支持许多相同的操作。例如，绘图程序可能有许多不同的工具，但每个工具都支持类似的操作，例如将笔放下或向上，以及在2个点之间画一条线。

在您的情况下，只有2个州，​​他们没有太多的行为。他们共享的主要内容是常见的GUI操作，这些操作可能已经存在于标准库中。您确实需要确保显示缓冲区之类的代码不会重复，但您可以在没有State模式的情况下执行此操作。

Answer 2

几年前，我在大学里做过类似的工作。

我会说使用状态模式对此有些过分，并且不完全适合，如前所述。我们对这项任务所做的是：

• 使用上面的 不同模式，允许在它们之间切换。
• 每种模式都不知道其他模式，他们不会互相打电话。
• 他们确实分享了模型的知识（在你的情况下是弹球板，保险杠，球等的位置），所以当你在它们之间切换它们是一致的。
• 就GUI而言，每种模式基本上都有空间来做这件事。就像你说的那样，每种模式都有不同的可能动作，因此强制它们作为状态模式的一部分共享相同的动作是“臭”。

基本上，正如其他地方所提到的，这两种模式没有足够的共同点来真正证明这里的状态模式。

应用状态模式有一种可能性，这是有意义的。由于这是一项大学任务，因此可能会对其背后的思想和理由充满信心。它与我前面提到的“上面的级别”有关。根据我的经验，这是独立于模式的GUI的一部分。它允许关闭应用程序，打开以前的弹球配置以及在模式之间切换。它还可以做的是显示依赖于上下文的菜单项。可以从当前模式检索菜单的状态。因此，构建器模式可以包括保存和其他构建器特定的操作，并且运行模式可以提供播放/暂停选项。如果您花时间调查状态模式，并希望获得回报，这将是一个可能的选择。

P.S。 Murray似乎对我们当时使用设计模式充满热情; - ）