1

我正在为一个简单的 iOS 井字游戏考虑这种设计模式：

  • GameState跟踪板上 X 和 O 位置的单例类
  • GameDisplay处理板的显示和触摸事件的单例类

这种状态和显示的分离似乎是合理的。GameDisplay可以将板上的点击转发到GameState板更新并检查获胜条件的位置。GameState可以反过来告诉GameDisplay绘制另一个 X/O 或游戏已完成以及获胜者是谁。我目前的计划是使用像GameState.playAtSquare(Square s)在两个单例之间进行通信的方法。

这种设计是否会成为使用单例的任何主要缺点的牺牲品？iirc 关于使用单例类存在一些争议。

4

3 回答 3

1

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

大多数情况下可以避免单例，在这种情况下也可以。相反，您不传递对GameStateand的引用GameDisplay吗？您可以将这两个类包含在诸如GameApplication类之类的东西中，而不是使其成为单例并过着应用程序的生命周期。

GameState如果你这样做，那么你避免GameDisplay成为单身人士，因为他们不一定需要是一个人。

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

于 2012-04-14T16:27:55.950 回答
1

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

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

GameDisplay应该是单个实例对象，它与Singleton不同。GameDisplay对象应该通过依赖注入传递给需要它的方法。

于 2012-04-14T16:30:59.497 回答
1

任何地方的单例的缺点与全局变量的缺点相同；也就是说，程序中具有状态的某些对象可以从程序中的其他任何地方直接访问和修改。

这对你的设计意味着你通过大胆假设你永远不能使用不同类型的 GameState 或不同类型的 GameDisplay 来在你的程序中建立刚性，因为你的程序的其余部分可能依赖于那些单例的存在。

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

There's almost always a preferable alternative to singletons. While some people are tempted by singletons because it involves "doing a bit less typing up-front", once your program starts to grow a little, it nearly always ends up being a source of unnecessary complexity, special cases and quirks.

于 2012-04-14T16:41:08.453 回答