GLOBALS vs CONSTRUCT

I got this problem some time ago... I already know a few positives and negatives of some, but I want some more review on this.

I used to use the following way to get objects to be used throughout the class...

And now, I'm getting the hang of "global"...

The good thing about the first way, is that it is good throughout the whole class, while using the second way, I have to put that for every function that uses those objects.

These objects are instantiated in a global file so they would be available globally throughout the site since they are the one most used objects in the site, and I guess classes void all that.. unless I put global where they are used... or if I use the construct thing, but then, if I change the class name, I'll have to change the class name in all those other classes I instantiated the object in the construct function...

You have to decide on a case-to-case basis which is better for each variable.

For instance,



That's a disaster waiting to happen. Depending on how many classes you have doing that, and how many instances you have at a given time, you could potentially have a lot of database connections going at one time, even if you made $this->db static.

Since your PHP application executes syncroniously rather than asyncroniously, lots of database connections is a bad thing.

However many instances of funcs might not be a bad thing depending on what the funcs class does.

Multiple instances of db might not even be a bad thing if your db class manages the number of connections and makes sure there's never more than needed.

How do I manage connections?

Your db class would have a static variable used to store the reference returned from mysqli_connect/etc, all instances would refer to that static variable, and your methods would ping the connection before use.

I use the following code to connect
Is that what you mean?

What do you mean by 'ping the connection before use'?

http://www.php.net/manual/en/function.mysql-ping.php



I personally don't like singleton classes.
I like to think that the only things worth writing classes for are things that will be instanciated at least twice.
I think once namespaces in PHP mature classes like that will not be used in new code.

What if I make __construct private?

Another question: What is the difference between self::function() or $this->function()?

'self' is used to reference the class that the static member resides in. 'this' is used to represent the member of an individual object.

So, 'self' = class-wide self-reference (used with static). 'this' = individual object's self-reference.

Also, globals are bad. They can be overwritten accidentally, and can make maintaining code more difficult in the long run. If you absolutely think you need global scope for some things, stick them in a Singleton. At least you'll be keeping some sort of encapsulation in place.

I am making a singleton class... that is why I am asking about making the __construct private for the database class and if I would need the mysql_ping in this case.

__construct should always be defined as a public method.

global is not bad, you should only be using the keyword "global" when you're already aware of the variable in the global scope and you need access to it.

If you're overwriting variables using global accidently you're a hacker, not a programmer.

Once again, the reason I made my __construct private is from this post. They didn't tell me not to do it

The real question here is about abstraction (bear with me here it will make sense). A singleton class or a global variable are both in the same global scope. What a singleton class provides is an abstraction for use.

For example:

No abstraction:
Take an integer variable, this is as basic as you can get, with no abstraction. You are able to directly edit this integer and do whatever arithmetic operations on it.

Function abstraction:
To abstract this requires controlling access to the variable and this is done by using functions/sub routine/methods. If this global variable was the constantly updated with the outside temperature you could provide getDegreesCentegrade() and getDegressFarienheit() functions. This would comprise your the interface to this variable.

Class abstraction:
Classes come into the picture when you want to control access to the data and group related functions and data together in a cohesive unit. This gives you the advantage of declaring your temperature variable private and provide methods to modify the variable. Perhaps a readOutsideTemperature() method. Granted this readOutsideTemperature() method could be a function, and then not make a class, but the downside would be that someone could still edit the temperature variable.


So the argument for the singleton class would be that it would allow you to provide a higher level of abstraction over using a global variable. However this can get tricky:



then later in a function:



would be (mostly) equal to the singleton solution:



They both provide equal abstraction and they are pretty much equal. The only difference is that in the global method someone can muck around with the $db variable in a function and produce a side effect. This is usually a bad thing. The only reason I can see for doing that would be to change what $db references thus changing the database connection. Changing the database connection should most likely be some service the abstraction layer provides.

In general you want to avoid global variables, however if you can come up with a good reason you can use them. However please use caution; they can bite you in unexpected ways.

As to the constructor in a singleton. It must be protected or private. This way the new operation can't be directly called on the object. The object must be allocated by a controlling static method usually something called like getInstance(). A protected constructor allows sub-classes while a private one would bar this from happening.

What's easier to understand, the freaking documentation that explains it's a singleton class that you should have read before using it anyway, or that odd-ball error message ?

I would hope the documentation would be easier to understand than a cryptic error.