在ROR 3.0中使用全局变量是不错的实践

Question

好的做法是在大型项目中使用全局变量需要更高的安全性（有些地方我读的不是DRY） 如果没有那么请解释原因？ Thanx提前

Answer 1

无论使用全局变量的位置，它们通常都是bad。

为什么在不必要时应避免使用全局变量

• 非本地化 - 当各个元素的范围有限时，源代码最容易理解。全局变量可以被程序的任何部分读取或修改，使得难以记住或推理每种可能的用途。
• 无访问控制或约束检查 - 程序的任何部分都可以获取或设置全局变量，并且可以轻松地删除或忘记有关其使用的任何规则。 （换句话说，获取/设置访问器通常比直接数据访问更受欢迎，对于全局数据更是如此。）通过扩展，缺少访问控制极大地阻碍了在您可能希望运行不受信任的代码的情况下实现安全性（例如使用第三方插件）。
• 隐式耦合 - 具有许多全局变量的程序通常在这些变量之间存在紧密耦合，以及变量和函数之间的耦合。将耦合项目分组为具有凝聚力的单元通常会带来更好的计划。
• 并发问题 - 如果多个执行线程可以访问全局变量，则需要同步（并且经常被忽略）。当动态链接模块与全局变量时，即使在几十个不同的上下文中测试的两个独立模块是安全的，组合系统也可能不是线程安全的。
• 命名空间污染 - 全球各地都有名字。当您认为使用本地（通过拼写错误或忘记声明本地）时，您可能会在不知不觉中最终使用全局，反之亦然。此外，如果您必须将具有相同全局变量名称的模块链接在一起，如果幸运的话，您将收到链接错误。如果您运气不好，链接器将只处理与同一对象同名的所有用途。
• 内存分配问题 - 某些环境具有内存分配方案，使得全局变量分配变得棘手。在“构造函数”具有除分配之外的副作用的语言中尤其如此（因为，在这种情况下，您可以表示两个全局变量彼此相互依赖的不安全情况）。此外，在动态链接模块时，可能不清楚不同的库是否有自己的全局变量实例或者是否共享全局变量。
• 测试和限制 - 使用全局变量的源更难以测试，因为在运行之间无法轻易建立“干净”的环境。更一般地，利用未明确提供给该源的任何类型的全局服务（例如，读取和写入文件或数据库）的源很难以相同的原因进行测试。对于通信系统，测试系统不变量的能力可能需要同时运行系统的多个“副本”，这在任何使用共享服务（包括全局内存）时都会受到很大阻碍，这些共享服务不作为测试的一部分提供共享