2012-07-08 97 views
1

在阅读了关于这个主题的SO线程之后:我想出了为什么全局变量/单例不好的原因。我可以在这种情况下使用全局变量吗?

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

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

现在,我知道全局状态不好,全局可变状态更糟糕,因为上述原因。但是看起来确实非常麻烦:做一个main()作用域的高度图对象,并将该高度图对象传递给每一个想要使用它的函数。

如果我100%确定应用程序中只有一个高度图,该怎么办?另外,由于这是一个小型的独立项目,我相信我能够理解每个功能对全球状态所做的事情?我不明白在这种情况下如何使用全局变量会影响单元测试。如果我想使用模拟高度图,在调用我想测试的函数之前,我不能仅仅执行globalHeightmap = generateMockHeightmap();吗?

+2

最有可能的情况是,高度图只是您的函数在其中运行的上下文的一部分。它应该与其他情况分组,而不是单独处理。 – 2012-07-08 04:38:06

+0

“但是看起来确实很麻烦,可以做另一种选择”如果这看起来很麻烦,那么你的代码架构不好。 – 2012-07-08 04:38:07

+0

只是举一个David Schwartz正在谈论的具体例子 - 创建一个包含高度图的类,并使需要访问高度图的函数成为此类的成员,以便您不必通过高度图明确。 – 2012-07-08 06:44:46

回答

1

就像你现在可能关于你项目的特征一样,我几乎可以向你保证,在将来的某个时刻,你需要修改依赖于这个全局变量的代码。在这一点上,全局变量可能会回来,并且让你更难找出所需的更改,因为状态不是隐藏的(例如,如果意外更改状态而不是从中读取状态,那么整个程序将受到影响在未来的某个随机点)。我不能夸大程序维护和调试的重要性,以尽量减少状态变化点,全局变量与这个目标几乎是相反的。

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

如果您想要将线程模型添加到您的应用程序会怎么样?使用全局状态将使这个过渡变得复杂得多。

如果有人从现在起一年内帮助您完成项目,该怎么办?他们能够理解代码吗? 从现在开始能够理解它(我知道我总是试着编写明显的代码并添加注释,因为我可能是一年后回来并不再记得某件事的人机制)。

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

相关问题