我们都知道全局变量是需要避免的，但是将它们放在命名空间中是解决方案还是相同问题的另一种形式？在命名空间中拥有任何人都可以访问和更改的数组之类的东西是否仍然很糟糕？
当你有一个变量时有没有其他选择：

• 不属于现有类
• 需要由多个现有类使用
• 不需要为每次使用创建一个实例(它们都应该修改同一个)

如果需要更多像这样的变量，所有这些变量都与同一个想法有关，命名空间会更容易理解。它们还使跟踪变得更容易。这些是唯一使他们比拥有全球更好的东西吗？我并不是要淡化它们的重要性，只是出于好奇。
多想想这个，C#中全局静态类成员的场景和这个基本一样。

编辑：毕竟最终为它创建了一个新类(并像往常一样通过 ref 传递它)。它有可能增长，所以我觉得这门课很好。另外，在写出命名空间之后，对于这种情况，它感觉就像一个可怕的解决方案。

全局变量存在(至少)三个不同的困难。他们：

1) 防止其他任何人使用相同的名字(或者如果他们这样做了，他们会掩盖您的名字，这可能会造成混淆)。将东西放在命名空间中有助于解决这个问题。

2) 很难同时推理所有直接修改全局的代码。除了匿名命名空间之外，命名空间对此无济于事，因为它们可用于将全局访问限制为一个 TU。使用私有静态类成员，也许使用一些 friend，会有所帮助。非可变全局变量也有帮助。

3) 很难同时推理所有间接修改全局的代码，因此很难推理全局的当前状态在程序中的任何指定点应该是什么。非可变全局变量有帮助。您不关心其状态的全局变量(例如，无论给定结果是否已缓存，只要正确处理缓存失效，它都不会影响代码的正确性)。命名空间没有帮助。 "隐藏"私有数据成员中的全局状态同时仍然保留公共访问器无济于事。

那么，命名空间是否有助于解决全局变量的困难？有一点，但不多。

如果您知道全局变量的其他困难，那么您可以自己评估名称空间是否有帮助。如果您没有意识到全局变量的困难，那么仅仅因为有人告诉你每个人都知道它们是坏的，就因为宗教信仰而避免它们对自己没有任何好处。一种了解的方法是询问愿意教你一些东西的人，而不是仅仅试图吓唬你成为一名优秀的程序员。另一种方法是使用它们，看看你遇到了什么麻烦，如果有的话。

当我们以 OOP 风格设计程序时，我们将其定义为实体的交互。实体在实现细节中隐藏它们的状态，并提供接口(使交互成为可能)。将所有实体定义为类已被证明是有效的。如果我们有全局变量，我们会妥协美并打破封装原则，让实体状态裸露在任何类之外。在这种情况下，命名空间帮不了我们。

我相信这真的只是同一个问题的一部分。在考虑将变量放入命名空间之前，为什么不问问自己，

问题)这个变量/数组是否可以在类的生命周期内包含在一个类中，而任何其他需要它的类都包含指向这个变量的指针/引用。

通常通过允许类通过指针访问变量，您可以像对待全局变量一样对待它，只需确保将其传递给构造函数，或者为其设置一个setter

通常，您的类想要封装一个对象状态，并使用函数来操作它。另一方面，命名空间可以更多地被认为是一组用于解决任务的相关函数，即带有类似...

的 std 命名空间

在此示例中，此命名空间中包含一些函数，用于将缓冲区打印到屏幕并刷新输出