Replacing the global variables, how and why

Question

Ok so I have worked and used my global variables until now, and it has been no problem in just calling $USER to get the user id.

Most times from people on SO and som

Answer 1

You will need to utilize sessions, and session variables.

Sessions allow php to create a unique identifier for each current user. By being to identify each individual user, php can create variables that are specific to this session.

For example, you will probably create session variables like $Session["memberID"], $Session["last_page_visited"], etc... The beauty part about this is that each Session can only access their variables, and nobody elses.

Also, session themselves will timeout after a set period of time. This will cleanup all variables that are associated with this session. This is why using global variables is a bit bad.

1. Global variables allow for unexpected results. You do not know WHERE the variable is coming from, or who has touched it last.
2. There is a global scope, so security is an issue
3. Memory usage. If you use global variables to store a lot of information, because there is no scope that data will stick around for a very long time. I'm not sure when global variables are cleaned up (if ever).

Answer 2

So this question is really two questions: why would I stop using global vars, and how should I implement similar functionality with another construct.

First, why you might want to stop using global vars:
Let me say that not using global variables is not a rule so much as a guideline. While there are zealots on both sides of the issue, there are some good reasons for and against it (though I've heard more against than for). Some reasons you might want to avoid global variables:

1. Access control
   This is probably the biggest and most solid reason for not using globals. With the global variable construct, any code can use the data stored in the variable any way it wants regardless of scope or reason. Access rules can be broken and the data can be invalidated by a reckless write. Unverified access means untrustworthy data.

2. Concurrency
   If you have a global variable, which by definition have no explicit access rules, concurrency can be a real issue. If two concurrently running instances or functions are accessing that same data, there is no way to guarantee the order in which reads or writes happen - further polluting your data.

3. Coupling/Structure/Code Clarity
   Simply put, when you're using global vars in OOPHP, it's likely you're coding your way around passing your data in a more direct way. Writing with globals implies tight coupling between the procedures using that data, as well as makes it difficult to understand the data flow. Refactoring is almost a necessity in most cases.

Second, how you can avoid global vars:

1. Static Vars/Objects
   One of the best ways to avoid globals is to wrap your "global" data in a static object. This allows you the minimum level of code safety of creating getters and setters around the data that can either bound check, access restrict, or at the least data lock your global variables as necessary. It may be a bit extra coding, but the level of data security you gain is worth it.

2. Refactor
   Think about the reason you're using your global data. Are you just trying to get around passing that data between functions? Are you trying to create persistent data that could be just as easily (and more effectively) be handled by $Session ? Often globals are stopgaps for quick and easy configurations or session work. Using config files or sessions add a level of functionality, extensibility, and security that is often worth the extra work.

There are a few cases where globals can be useful. In very small programs, where data security is entirely irrelevant, or where your data is TRULY used throughout the code with no good clear way of passing it or avoiding scope issues, it may be alright to use global vars, but in general they're bad practice.

A good way to think about it is "what would happen to my script if my global data turned out to be garbage." If the answer is anything but "not much, really," then you should probably find a way to protect that data or to rethink the way you're using it.