error_reporting(E_ALL | E_STRICT);

You will get many many error messages in your code, where you are using this technique.

Also, if you turn on zend comp. model, you will fail in use singleton.

The only problem you appear to have with the singleton pattern is the requirement for a private constructor. Make it public and your objections go away. For me the pattern is not so much about control than it is about convenience. Everything related to my database connections is taken care of by one class in one file. If I need more flexibility I simply change that one file to bend the way I need it to while maintaining the existing contract so I don’t need to change any other files.

For most web-based applications a single database connection is the only one that’s needed. In that situation I see no problem using a singleton to manage that connection. If your application needs more than that then a singleton is obviously not the way to go. Likewise with logging as an example, most apps will only need one log so a singleton makes sense there too.

As I mentioned in my previous comment the project I currently spend most of my time on uses a database class that can manage a number of connections but it’s still controlled. The application begins by making one or more calls to DB::AddConnection() passing all the details required for each connection along with a short name by which it can be referred. Anything that then needs a connection calls DB::Connection() and passes the short name of the connection it wants (read, write, stats, etc) and the class ensures that only one resource for each connection is ever created while providing many useful methods for retrieving and manipulating data.

In this particular situation a strict singleton pattern was not suitable so I modified it to manage more than one instance. The constructor is still private and all instance management is handled within the class. This meets all my requirements, none of which have anything to do with the trust I have in the developers on my team.

If you need to be able to create and destroy the database connection for testing purposes all you need to do is add a static method to the class to destroy the singleton instance. Rocket science it ain’t, and for me that requirement is not a good enough reason to avoid the pattern completely.

If you don’t like the idea of a singleton but still want the advantages the functionality can be duplicated using a modified factory pattern where it knows which objects should be singletons. Personally I prefer to keep information like that inside the class in question. This is effectively what your get_db() function is doing, albeit for a single class.

Check out http://c2.com/cgi/wiki?SingletonsAreEvi for a discussion on the topic (that wiki is a black hole for free time, seriously).

I don’t understand how using a singleton database class is more restrictive than your get_db() function when it comes to creating arbitrary connections. In addition whatever pattern you use can be written with any amount of flexibility you desire. I use a singleton class because it contains a number of helper methods to make certain database operations easier, but it also provides access to the raw resource if required. It also supports multiple connections (read, write, stats) but that’s neither here nor there.

I also don’t see why the limited life of objects in a PHP request is a factor? I prefer to write well-engineered code regardless of how long each instance will exist. I also prefer maintainable and reusable code, and singletons help me towards those goals in certain situations.

In regard to not trusting downstream devs, how exactly is a singleton different in that respect from your get_db() function? Aside from that it’s not an issue of trust, it’s a question of the right tool for the job. Singletons are as much about minimising resource usage as they are about anything else. They aid me in creating self-documenting code such that users of my class don’t need a lesson before being able to use it properly.

But uhh… not that I want to discourage you – I like getting comments. And I’m glad you’re liking these snippets .

You want a single database connection? Make a function called get_db() that returns a local static Database object. That’s better than forcing Database to be a singleton, because it provides additional flexibility (ability to create arbitrary connections, should the need arise) with no obvious drawbacks.

This is particularly true in a language like PHP, where the scope of any object is at most for a single request.

In most cases I’ve seen, the desire for a software designer to limit the number of instances of an object boils down to being a control issue, and a mistrust in the discipline of downstream developers. I consider this an issue to solve with education, rather than jumping through hoops in the code (KISS principle).

But uhh… not that I want to discourage you – I like the list of PHP snippets.