在阅读了关于这个主题的一些SO主题之后：我已经提出了为什么全局变量/单例不好的原因。
我想用C ++制作游戏，并且会有一个“高度图对象”代表我游戏中的世界景观高度图。此高度图可以更改。我想为它使用一个全局对象。 （我不希望遇到静态初始化顺序问题，因为没有任何其他静态变量引用此高度图对象）。
现在，我知道全球状态很糟糕，由于上述原因，全球可变状态更糟。但是，做替代方案似乎非常非常麻烦：在main()范围内创建一个高度图对象，并将该高度图对象传递给每个想要使用它的函数。
如果我100％确定应用程序中只有一个高度图，该怎么办？此外，由于这是一个小型的独立项目，我相信我能够理解每个功能对全球状态的影响吗？我不知道在这种情况下如何使用全局变量会损害单元测试。如果我想使用模拟高度图，在调用我想测试的函数之前，我不能只做globalHeightmap = generateMockHeightmap();吗？
答案 0 :(得分：1)
就像你现在可能对项目的特性一样，我几乎可以向你保证，在将来的某个时候你需要修改依赖于这个全局变量的代码。此时全局变量可能会返回并使您更难以找出所需的更改，因为状态未被隐藏（例如，如果您不小心更改状态而不是从中读取，那么整个程序会受到影响在未来的某个随机点）。我不能夸大程序维护和调试对于最小化状态变异点的重要性，而全局变量几乎与该目标完全相反。
覆盖单元测试的全局状态映射似乎很脆弱。如果您需要恢复旧状态，或者在测试状态之间进行变异，该怎么办？然后你最后得到一堆保存/设置/恢复代码。
如果您想在应用程序中添加线程模型，该怎么办？使用全局状态将使这种过渡变得更加复杂。
如果其他人一年后帮助你解决这个项目怎么办？他们能够理解代码吗？从现在开始你能够理解它吗（我知道我总是试着编写明显的代码并在不具体的地方添加评论，因为我可能是一年后回来的人而且没有更长时间记住关于机制的事情。）
最后，如果一个非全局变量的方法似乎太多工作或太复杂，可能意味着你的替代方法太复杂或需要另一个想法/返工。没有理由不能将高度图存储到在适当的高级游戏对象中创建的对象中，并根据需要传递/存储在较低级别的对象中。