5

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

我最初的想法是状态模式——但是，我担心状态之间的公共接口可能会将它们收缩为不适合该状态的实现方法。

例如。在建造者模式下，设置保险杠或其他东西的位置是完全合适的；但是在运行模式下，它会被实现为什么都不做或抛出异常——这看起来很讨厌，尤其是如果有很多这样的方法。

有没有更好的设计呢？

4

2 回答 2

11

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

在您的情况下，只有 2 个状态，并且它们没有太多的行为。他们共享的主要内容是可能已经在标准库中的常见 GUI 操作。您确实需要确保用于显示保险杠之类的代码不重复，但您可以在没有状态模式的情况下做到这一点。

于 2010-01-27T19:45:09.840 回答
1

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

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

  • 使用高于不同模式的东西，允许在它们之间切换。
  • 每个模式都不知道另一个模式，它们不会互相调用。
  • 不过，它们确实共享模型的知识（在您的情况下是弹球板，带有保险杠、球等的位置），因此当您在它们之间切换时，它们是一致的。
  • 在 GUI 方面，基本上每种模式都有空间去做它的事情。就像你说的，每种模式都有不同的可能动作，所以强迫它们作为状态模式的一部分共享相同的动作是“臭的”。

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

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

PS Murray 当时似乎对我们使用设计模式充满热情；-)

于 2010-01-27T22:33:22.000 回答