简单游戏中的基本设计模式

Question

我正在考虑这个简单的iOS tic-tac-toe游戏的设计模式：

• GameState单一类，用于跟踪棋盘上的X和O位置
• GameDisplay用于处理电路板显示和触摸事件的单例类

这种状态和显示的分离似乎是合理的。 GameDisplay可以将电路板上的抽头转发到更新电路板的GameState，并检查获胜条件。 GameState可以反过来告诉GameDisplay绘制另一个X / O或游戏是否完整以及获胜者是谁。我目前的计划是使用像GameState.playAtSquare(Square s)这样的方法在两个单身人士之间进行交流。

这种设计是否会成为使用单身人士的主要缺点的牺牲品？ iirc对使用单身人士课程存在一些争议。

Answer 1

仍然存在依赖关系和潜在的线程问题（如果您不采取预防措施）。

大多数情况下可以避免单身人士，在这种情况下也可以。相反，你没有传递给GameState和GameDisplay的引用？您可以将这两个类包含在诸如GameApplication类之类的内容中，而不是它是单例并且在应用程序的生命周期中存在。

如果你这样做，那么你就不会让GameState和GameDisplay成为单身人士，因为他们不一定需要一个人。

有关处理没有单身人士的游戏状态的示例，请查看Gamestate management without evil Singletons。

Answer 2

我认为在这种情况下你应该不使用Singleton。

使用对象来表示GameState（或Game），因为它允许您同时允许（例如）多个游戏。

GameDisplay应为single instance object, which is different than a Singleton. GameDisplay对象应通过Dependency Injection传递给需要它的方法。

Answer 3

单身人士在任何地方的缺点都与全球变量的缺点相同;也就是说，程序中某个具有状态的对象可以从程序中的任何其他位置直接访问和修改。

对您的设计意味着您通过大胆假设您永远不会使用其他类型的GameState或不同类型的GameDisplay来建立您的程序的刚性，因为您的程序的其余部分很可能取决于那些单身人士的存在。

在将单身人士“焊接”到程序中之后，这种情况经常会出现问题 - 对GameState和GameDisplay的任何后续更改可能会对程序的其余部分产生无意的连锁效应，并找到“变通办法”来限制或停止这些更改的效果可能会导致代码中其他地方的丑陋/ hacky解决方案。

对于单身人士来说，几乎总是有一个更好的选择。虽然有些人受到单身人士的诱惑，因为它涉及“少做一点打字”，一旦你的程序开始增长一点，它几乎总是最终成为不必要的复杂性，特殊情况和怪癖的来源。