1

在阅读了关于这个主题的一些 SO 主题之后：我想出了这些为什么全局变量/单例不好的原因。

  1. 理解全局状态的函数变得越来越困难，随着代码的增长，越来越多的函数将修改该全局状态。
  2. 它使单元测试更难。
  3. 它隐藏了依赖关系。
  4. 如果有一天你的全局变量实际上不是一个单一的对象/变量，你将不得不重写代码。

我想用 C++ 制作一个游戏，会有一个“高度图对象”将我的游戏中的世界景观表示为高度图。这个高度图可以改变。我想为它使用一个全局对象。（我不希望遇到静态初始化顺序问题，因为不会有任何其他静态变量引用此高度图对象）。

现在，由于上述原因，我知道全局状态很糟糕，而全局可变状态更糟。但是这样做似乎真的非常麻烦：在main()范围内创建一个高度图对象，并将该高度图对象传递给每个想要使用它的函数。

如果我 100% 确定我的应用程序中只有一个高度图怎么办？此外，由于这是一个小型的单独项目，我相信我将能够理解每个函数对全局状态的作用？而且我看不出在这种情况下使用全局变量会如何损害单元测试。如果我想使用模拟高度图，我不能globalHeightmap = generateMockHeightmap();在调用我想测试的函数之前做吗？

4

1 回答 1

1

尽管您现在对项目的特征很确定，但我几乎可以向您保证，在将来的某个时候，您将需要修改依赖于这个全局变量的代码。到那时，全局变量可能会回来，使您更难找出所需的更改，因为状态没有隐藏（例如，如果您不小心更改了状态而不是从中读取，那么整个程序都会受到影响在未来的某个随机时间点）。我不能夸大它对于程序维护和调试的重要性，以最小化状态突变点和全局变量几乎是该目标的对立面。

只是为您的单元测试覆盖全局状态图似乎很脆弱。如果您需要恢复旧状态，或者在测试中的状态之间发生变异怎么办？然后你会得到一堆保存/设置/恢复代码。

如果您想在应用程序中添加线程模型怎么办？使用全局状态将使转换变得更加复杂。

如果一年后其他人帮助您完成该项目怎么办？他们能理解代码吗？一年后你能理解它吗（我知道我总是尝试编写明显的代码并在不明确的地方添加注释，因为我可能是一年后回来的人，不再记得有关机制的事情）。

最后，如果非全局变量方法看起来工作量太大或太复杂，这可能意味着您的替代方法太复杂或需要另一个想法/返工。没有理由不能将高度图存储到在适当的高级游戏对象中创建并根据需要传递/存储在较低级别对象中的对象中。

于 2012-07-08T05:03:26.120 回答