在需要更多安全性的大型项目中使用全局变量是否是良好做法（我读到的一些地方不是 DRY），如果没有，请解释原因？提前感谢
问问题
769 次
1 回答
4
无论在哪里使用全局变量，它们通常都是bad。
为什么在不必要时应避免使用全局变量
- 非局部性——当单个元素的范围有限时，源代码最容易理解。全局变量可以被程序的任何部分读取或修改，因此很难记住或推理每种可能的用途。
- 没有访问控制或约束检查——程序的任何部分都可以获取或设置全局变量，并且任何关于其使用的规则都可以很容易地被破坏或遗忘。（换句话说，get/set 访问器通常比直接数据访问更可取，对于全局数据更是如此。）通过扩展，在您可能希望运行不受信任的代码的情况下，缺乏访问控制极大地阻碍了实现安全性（例如使用 3rd 方插件）。
- 隐式耦合——具有许多全局变量的程序通常在其中一些变量之间存在紧密耦合，以及变量和函数之间的耦合。将耦合的项目分组为有凝聚力的单元通常会导致更好的程序。
- 并发问题——如果全局变量可以被多个执行线程访问，同步是必要的（而且经常被忽略）。当动态链接模块与全局变量时，即使在几十个不同上下文中测试的两个独立模块是安全的，组合系统也可能不是线程安全的。
- 命名空间污染——全局名称随处可见。当您认为您正在使用本地（通过拼写错误或忘记声明本地）时，您可能会在不知不觉中最终使用全局，反之亦然。此外，如果您必须将具有相同全局变量名称的模块链接在一起，如果幸运的话，您会遇到链接错误。如果你不走运，链接器将简单地将所有使用相同名称的对象视为同一个对象。
- 内存分配问题——某些环境的内存分配方案使得全局变量的分配变得棘手。在“构造函数”具有分配以外的副作用的语言中尤其如此（因为在这种情况下，您可以表达两个全局变量相互依赖的不安全情况）。此外，当动态链接模块时，可能不清楚不同的库是否有自己的全局实例或全局是否共享。
- 测试和限制 - 使用全局变量的源代码更难测试，因为在运行之间无法轻松设置“干净”的环境。更一般地，利用未明确提供给该源的任何类型的全局服务（例如读取和写入文件或数据库）的源由于相同的原因而难以测试。对于通信系统，测试系统不变量的能力可能需要同时运行一个系统的多个“副本”，这会受到任何共享服务（包括全局内存）的使用的极大阻碍，这些共享服务并未作为测试的一部分提供共享.
于 2012-09-11T10:54:50.633 回答