c++ - 做OOP状态机设计时如何避免单例？

Question

我正在尝试自学编程。我相信大多数人都是以同样的方式开始的；制作小而杂乱的应用程序和游戏，以不那么简单的方式做简单的事情。最近，我一直在尝试通过编写一个稍微复杂一些的游戏来进行下一步，该游戏使用 OOP 设计来编写更好、更模块化的代码!

我一直遇到的主要问题是我的主要 StateManager (FSM) 类的设计(在介绍/菜单/游戏/等屏幕状态之间切换)。我看了高低，真正看到的只有两种设计方法:

• 使用 switch/case 语句 + 枚举在状态之间切换..

• 制作一个单例 FSM 类来处理向/从 vector 插入/弹出状态。

现在，我的问题是，switch case 语句非常重复和笨拙，这有点违背我使用这个项目自学 OOP 的目标。

我的第二个也是更大的问题是“单例”建议。

正如我之前所说，我正在努力自学，但在编程方面我还有很多东西要学，尤其是在 OOP 和设计模式等领域。我遇到了一个问题，对于我发现的每一个“单例是邪恶的”线程和讨论，我发现人们在他们的代码中使用单例来制作“引擎”类和 FSM 的教程和引用资料一样多. 这是一个非常一致的混合信息。

我想我只是不明白为什么...即使您只想/打算拥有一个类的单个对象，为什么将构造函数设为私有(private)并创建一个单例是必要的/有益的？我读过很多关于单例有多糟糕，它们本质上是全局的，它们如何妨碍多线程，以及有多少程序员认为它们被过度使用或只是简单的糟糕设计......但我看到了一个又一个的例子的人使用它们，并且很少有反例显示替代方法。

难道同样的事情只用一个普通的类(class)就可以完成吗？明确限制创建实例的目的是什么？我只听说过有关单例的负面消息，但人们似乎经常使用它们……我是否完全遗漏了有关单例和 OOP 的一些信息？

单例的使用只是一种趋势，还是人们称单例为“邪恶”的只是一种趋势？我该如何解决这个问题..？ switch/case FSM 和单例 FSM 之间没有什么东西吗？难道有人不能以完全相同的方式设计他们的程序的状态系统而不使他们的任何类成为单例吗？这会改变什么吗？ [困惑]

Answer 1

Couldn't the same type of thing be done with just a regular class? What's the purpose of explicitly restricting the creation of instances? I've heard only negative things about singletons, yet people seem to use them constantly... Am I completely missing something about singletons and OOP?

不，我相信您走在正确的轨道上:绝对没有理由阻止创建两个实例。宇宙不会因此而内爆。

这是一个完全没有必要的限制。由于您必须手动编写该限制，因此拥有它是非常愚蠢的(如果您必须编写代码来解除它，那将是另一回事)。

我想可能会出现奇怪且罕见的情况，如果创建第二个实例，宇宙确实会发生内爆，但这听起来很牵强。无论如何，这并不能证明单例在整个 Internet 上的流行是合理的。

我真的无法解释为什么人们经常使用它们而不侮辱那些人的推理能力，所以我不会这样做。

Couldn't someone design their program's state system the exact same way without making any of their classes singletons? Would that change something?

唯一改变的是，通过将其设为单例，您可以防止自己为单元测试创​​建一次性实例。其他一切都一样。