使用或不使用状态模式？

Question

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

我最初的想法是国家模式 - 但是，我担心的是国家之间的共同接口可能会将它们收缩为实施不适合该州的方法。

例如，在建造者模式下，设置保险杠的位置或任何东西都是完全合适的;但在运行模式下，它将被实现为无所事事或抛出异常 - 这看起来很讨厌，特别是如果有很多这样的方法。

有没有更好的设计呢？

Answer 1

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

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

Answer 2

几年前，我在大学有一个类似的任务。

我会说使用状态模式对于这一点是过度的，以及不完全适合，如前所述。我们所做的这个任务是：

• 使用的东西以上不同的模式，这使得他们之间的切换。
• 每种模式都不知道其他模式，它们不会互相调用。
• 虽然他们确实分享了模型的知识（在你的情况下是弹球板，保险杠，球等位置），所以当你在它们之间切换时，它们是一致的。
• 就GUI而言，每种模式基本上都有空间来做它的事情。就像你说的那样，每种模式都有不同的可能行为，所以迫使他们分享相同的行为作为国家模式的一部分是“臭”。

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

有一种应用状态模式的可能性，这是有道理的。由于这是一项大学任务，因此背后的想法和理由可能值得赞扬。这与我之前提到的“高于上一级”有关。根据我的经验，这是独立于模式的GUI的一部分。它允许关闭应用程序，打开以前的弹球配置，以及在模式之间切换。它也可以做的是显示上下文相关菜单项。菜单的状态可以从当前模式中检索。因此，构建器模式可以包括保存和其他构建器特定的操作，并且运行模式可以提供播放/暂停选项。如果你花时间研究了国家格局，并希望能够得到回报，这将是一个可能的选择。

P.S.Murray当时看起来对我们使用设计模式似乎很热心;-)