全局变量问题

alazer

“C++程序设计陷阱  ”一书中关于全局变量的说明，我有点疑问：

1. 常见错误3：全局变量
   
2. 
   
3. 很难找到任何理由去硬生生地声明什么全局变量。全局变量阻碍了代码重用，而且使代码变得更难维护。它们阻碍重用是因为任何使用了全局变量的代码就立刻与之耦合，这使得全局变量一改它们也非得跟着改，从而使任何重用都不可能了。它们使代码变得更难维护的原因是很难甄别出哪些代码用了某个特定的全局变量，因为任何代码都有访问它们的权限。
   
4. 
   
5. 全局变量增加了模块间的耦合，因为它们往往作为幼稚的模块间消息传递机制的设施存在。就算它们能担此重任，从实践角度来说，要从大型软件的源代码中去掉任何全局变量都几乎不可能 。这还是假定它们能正常工作的情况。不过可不要忘了，全局变量是不设防的。随便哪个维护你代码的C++新手，都能使对全局变量有强烈依赖的软件随时崩溃。
   
6. 
   
7. 全局变量的辩护者们经常拿它的"方便"来说事。这真是自私自利之徒的无耻之争。要知道，软件的维护常常比它的初次开发要花费更多时间，而使用全局变量就意味着把烂摊子扔给了维护工程师。假设我们有一个系统，它有一个全局可访问的"环境"，并且（我们按需求保证）确实只有"一个"。不幸的是，我们选择了使用全局变量（来表示它）：
   
8. 
   
9. extern Environment * const theEnv;
   
10. 在软件就要交付之前，我们会发现，可能同时存在的环境要增加到两个、三个，或是在系统启动时指定的，或根本就是完全动态的某个数。这种在软件发布的最后时刻发生的变更实属家常便饭。在备有无微不至的源代码控制过程的大项目里，这个变更会引发极费时间、涉及所有源文件的更改，即使在最细小的和最直截了当的那些地方也不例外。整个过程预计要几天到几星期不等。假如我们不用全局变量，只要五分钟我们就能搞定这一切：
    
11. 
    
12. Environment *theEnv();
    
13. 仅仅是把对于值的访问加上了函数形式的包装，我们就获得了可贵的可扩充性。要是再加上函数重载，或是给予函数形式参数以默认值，我们就根本不需要怎么改源代码了。
    
14. 
    
15. Environment *theEnv( EnvCode whichEnv = OFFICIAL );

复制代码

他这样做法，是不是将原有的一个全局变量定义，变成了一个全局函数的定义？？？
比如上述中的 Environment *theEnv();
原来通过一个全局变量，各个类（文件）等都直接饮用该变量。
当换成该函数时，是不是每个类（文件）都只不过通过theEnv指针访问？？


我现在面对的问题是：
Environment的各个参数，一个模块内部许多类都需要用到，独立成一个全局变量（或者上述的全局函数）较为合适。

但是，程序需要启动多个该模块，比如启动2个该模块，但这2个使用的Environment却不同，这时候该如何处理？？

efolzl

没啥问题啊，就是你理解的那样~

alazer

我现在面对的问题是：
Environment的各个参数，一个模块内部许多类都需要用到，独立成一个全局变量（或上述的全局函数）较为合适。

但是，程序需要启动多个该模块，比如启动2个该模块，但这2个使用的Environment却不同，这时候该如何处理？？

davelv

程序需要启动多个该模块，比如启动2个该模块，但这2个使用的Environment却不同，这时候该如何处理？？

全局变量也不是处理这种情况的存在。
这是给类的成员变量/函数的的作用范围。