To address your statement, it’s not so much about how unique each individual singleton is, but rather about the duplication of code used to simply implement the logic behind instantiating a singleton in the first place. Consider the concept of DRY as it applies to minimizing duplication of logic and, where possible, reducing boilerplate code. While you’re database class will hold very different methods and fields than your session singleton, they both share the core logic of creating a single instance of themselves through a private constructor called by a static initializer: this is where abstraction and centralization of code would be most useful.

Does that make sense? I enjoy conversations like these

I actually use the Singleton classes for the Database connection, Logger, Debugger, Session manager and Current User. All those instances should be unique around the whole application so I guess this is “ok”
Any advice or comment on this ?

@Chris: Certainly, you can absolutely extract out your public methods in the DB_Connection class into an Interface, and yes, it would be helpful – for DB_Connection. However, that doesn’t really get you any wins in regards to encapsulating the logic germane to the Singleton pattern itself (#__construct and #getInstance, and the $instance field). This was what I was talking about in that it rather sucks to have to re-implement this boilerplate code every time you need a Singleton. Now, that being said, hopefully you’re not going to be using too many Singletons in your code anyway, but that’s tangential . Thanks for the comment!

Couldn’t we define an interface declaring connect and query methods to be used ? Might be useful sometimes

Either way, good post John. I’ve already bookmarked this blog and sent you out to 20 of my programming friends.