Singleton PHP - database handler

Question

I have been reading a bit lately about the singleton pattern. When readin the technical aspects of it, it appears to be ideally suited to managing a database handler or the likes. But after reading wider resources it appears that the developer community really does not favour the pattern.

I am struggling to find a better solution to such a problem - i.e. only a single handler can be initialised at a time - so why is the pattern so bad? Is it overused or is it just fundamentally flawed?

Php is the language that I am using.

Answer 1

Singletons are glorified global variables. The design pattern was created for languages in which global variables are difficult or impossible, or where they are considered bad practice. (In fact, most of the common design patterns are designed for restrictive languages. A great number of them are simply unnecessary in other languages.)

PHP has global variables. PHP global variables are usually a bad practice, but they do exist if you need to use them.

However, there are a few reasons you'd want a Singleton in PHP.

Singletons are useful when the call to getInstance (the canonical name for the method that returns the single instance of the Singleton) might me made at any point in the script. Up until that point, the object doesn't need to exist. If the object was a global variable instead, either it would have to already exist, or the code trying to reference the object would first need to instantiate it. In fact, anywhere that it could be used, it would need to be instantiated correctly. By centralizing the creation of the single object in getInstance, you avoid having to create copy-and-paste boilerplate every time you need to reference the object.

Database objects usually get created very early on in the request lifetime, so that specific benefit of Singleton-ness would be wasted.

There are other alternatives to Singleton that can get the job done in other ways. One example is dependency injection, a fancy term for passing external objects that a new object would depend on (such as a database handle) to the object at construction time. However, this can be complicated or annoying. Doing it right might involve injecting a lot of the same objects every single time.

Another alternative is the Registry pattern, which is effectively a container for things that would otherwise be globals. If you don't like global variables, but don't mind them being effectively namespaced, this would be a solution that you'd like.

In the end, pick one way to do it, and stick with that one way throughout your codebase. Personally, I'm a fan of the database object being a global.

Answer 2

Some people follow this mantra that Singletons are evil because they are like global variables and make your code more hard-coupled and harder to test.

I for one don't think it's such a bad idea, and I think a Singleton works pretty well for a database handler. It's easy, intuitive, and you have more control over a Singleton instance than you would a global variable.