MrK*_*ish 8 c++ oop singleton fsm
我正在努力教自己编程.我开始的方式与我相信大多数人的开始方式相同; 制作小而凌乱的应用程序和游戏,以不那么简单的方式做简单的事情.最近,我一直试图通过编写一个使用OOP设计的更复杂的游戏来编写更好,更模块化的代码来迈出下一步!
我遇到的主要问题是我的主要StateManager(FSM)类的设计(在介绍/菜单/游戏/等屏幕状态之间切换).我看起来又高又低,我真的只看到了两种设计方法:
使用switch/case语句+枚举来切换状态.
创建一个单独的FSM类,用于处理向量/从向量中推送/弹出状态.
现在,我的问题是,switch case语句是非常重复和笨重的,它有点违背我使用这个项目来教自己OOP的目标.
我的第二个也是更大的问题是"单身人士"的建议.
正如我之前所说,我正在努力自学,在编程时我还有很多需要学习的东西,特别是在OOP和设计模式以及所有这些方面.我遇到了一个问题,对于我发现的每一个单身"单身都是邪恶的"线索和讨论,我发现很多教程和参考,其中人们在他们的代码中使用单例来制作'引擎'类和FSM.这是一个非常一致的混合信息.
我想我只是不明白为什么......即使你只想要/打算拥有一个类的单个对象,为什么使构造函数私有并创建一个单例是必要/有益的？我已经阅读了很多关于单身人士是如何坏,他们如何基本上是全球性的,他们如何妨碍多线程,以及有多少程序员认为他们过度使用或只是简单的糟糕设计......但我看到例子后面的例子人们使用它们,很少有反例显示替代方法.
只用常规课可以做同样的事吗？明确限制实例创建的目的是什么？我只听过关于单身人士的消极事情,但人们似乎经常使用它们......我完全错过了关于单身人士和OOP的事情吗？
单身人士的使用只是一种趋势,还是只是人们称单身人士为"邪恶"的趋势？我该怎么解决这个问题？开关/外壳FSM和单独FSM之间没有什么东西？有没有人能够以完全相同的方式设计他们的程序的状态系统,而不需要他们的任何课程单身人士？这会改变什么吗？[ confused ]
只用常规课可以做同样的事吗？明确限制实例创建的目的是什么？我只听过关于单身人士的消极事情,但人们似乎经常使用它们......我完全错过了关于单身人士和OOP的事情吗？
不,我相信你走在正确的轨道上:绝对没有理由阻止创建两个实例.宇宙不会因此而崩溃.
这是一个完全不必要的限制.因为你必须手动编写这个限制,所以完全拥有它是非常愚蠢的(如果你必须编写代码来解除它,那将是另一回事).
我想可能有一些奇怪而罕见的情况,如果第二个实例被创建,宇宙会崩溃,但这听起来很牵强.无论如何,它并不能证明整个互联网上单身人士的普遍存在.
我无法解释为什么人们不经常使用它们而不侮辱那些人的推理能力,所以我不会这样做.
有没有人能够以完全相同的方式设计他们的程序的状态系统,而不需要他们的任何课程单身人士？这会改变什么吗？
它唯一改变的是,通过使它成为单身,你可以防止自己为单元测试创建一次性实例.其他一切都是一样的.
| 归档时间： |
|
| 查看次数： |
1873 次 |
| 最近记录： |