The Singleton Pattern is one of the GoF (Gang of Four) Patterns. This particular pattern provides a method for limiting the number of instances of an object to just one. It's an easy pattern to grasp once you get past the strange syntax used.

Consider the following class:

This class creates a connection to our database. Any time we need a connection we create an instance of the class, such as:

Lets say we use the above method many times during a script's lifetime, each time we create an instance we're creating a new Database object (we're also creating a new database connection, but that's irrelevant in this example) and thus using more memory. Sometimes you may intentionally want to have multiple instances of a class but in this case we don't.

The Singleton method is a solution to this common problem. To make the Database class a Singleton we first need to add a new property to the class, we'll call this $m_pInstance:

As the comment states, this property will be used to store the single instance of our Database class. You should also note that this property must be static.

Next we need to change the constructor's scope to private. This is one of the strange syntaxes that usually confuse people.

By making the constructor private we have prohibited objects of the class from being instantiated from outside the class. So for example the following no longer works outside the class:

We now need to add a method for creating and returning our Singleton. Add the following method to the Database class:

This funny looking function is responsible for handling our object instance. It's relatively easy to understand, basically we check our static property $m_pInstance, if it is not valid we create a new instance of the Database class by calling the constructor. Remember, we made the __construct() method private, so an instance of the object can only be created from within the class' methods. Finally the function returns a reference to our static property. On subsequent calls to getInstance(), $m_pInstance will be valid and thus the reference will be returned - no new instances are created.

So our Database class now looks something like this

You can now get an instance of the Database class from anywhere (without using globals or function arguments) in your project. Here's an example and comparison:

This is the usual way we create objects:
This is the Singleton way:
To conclude, the Singleton is an easy-to-use design pattern for limiting the number of instances of an object. See the attached files for working examples.

Attached Files

	default.php (776 Bytes, 5700 views)
	singleton.php (1.1 KB, 9330 views)

__________________
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Looks nice :D I will study the examples ;)

And thanks for a great tutorial :)

to further enforce this pattern you may want to either make the magic method __clone() private or just make the script die when this function is called, this is so that clones of the singleton object cannot be made.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

What a great PHP singleton tutorial. By implementing the __clone method you certainly won't be getting past it!

__________________
The man who comes back through the Door in the Wall will never be quite the same as the man who went out.

Great tutorial, I will definitely use this technique in my coding.

I'm having some trouble getting my Singleton to hold state.

I have a class that implements the Singleton pattern and has a member called $sessionState which is meant to hold a string value denoting the current state of the Singleton instance.

Now, maybe it's my lack of understanding when it comes to sessions, but every time I retrieve an instance of my Singleton class, the $sessionState member gets reset.

Code fragments follow:

As you can see, I want the Initialize method to check the current value of $sessionState and respond accordingly. After a successful intialization of SessionMonitor, the $sessionState should be updated from 'Not Initialized' to 'Running' (which testing proves DOES happen). I'd expect, then, that any subsequent calls to other Control methods which depend on the value of $sessionState would read a value of 'Running'.

Such as...

If I call this method (after a successful call to Initialize), the case block for 'Running' doesn't execute, as the value for $sessionState seems to get reset to 'Not Initialized'.

What am I missing? Are Singleton instances cleared/collected with subsequent http requests to the same php file?

Something I'll usually do is overload the class name with a function:
This, in combination with usually returning an object simplifies instruction chaining (and, as a result, code readability) greatly.

Oooo... session-level singleton. Not a bad idea, especially in the case of, for example, a User or Visitor model.

Still, your best bet with that is to store the class instance in the $_SESSION variable, and define the __sleep and __wakeup methods accordingly.

Yes. Yes they are. In fact, between requests, the only things that hang out are the contents of $_SESSION (if session_start() has been called), files, and databases. No other variables are retained.

A very useful design pattern indeed, thanks for the clear tutorial Karl

__________________
Search Marketing

Great tutorial. It actually looks a lot like the way I did my singleton pattern.. lol

Here it is:

Why would you call your DB class "Singleton"? Singleton is the name of the pattern, not a standard name for a DB class..

__________________
Nunchaku! Who doesn't like martial arts? =)

Yeah, and why all this talk about singleton in PHP when ALL variables containing a singleton is destroyed on new request.

It seems we have this great pattern that is absolutely useless when it comes to singleton and sessions.

How do I store a language variable in a session using a singleton without it being destroyed on every request.

I'd like to avoid having to add a lang=n to all links througout a whole website, but store a language value i session using a singleton?

You could store it in a cookie or database.

__________________
My Site

And that would meen a roundtrip to a file on the client, or the database on the server. It seems pretty lame, that you cannot simply store a single instance of an object in a server variable.

It was an example, brosef.

great tut.... how about this? removing the extra method prepare() and moving the code into the __cunstruct

class Config
{
const DB_HOST = "localhost";


const DB_USERNAME = "uuu";



const DB_PASSWORD = "pppp";



const DB_NAME = "bbbb";
}






final class Database extends Config
{

protected static $dbConnection;
protected static $database = NULL;

protected function __construct () {

self::$dbConnection = new mysqli
(
parent::DB_HOST,
parent::DB_USERNAME,
parent::DB_PASSWORD,
parent::DB_NAME
);

if (mysqli_connect_errno())
{

throw new Exception('Unable to connect to database');
}

}

protected function __clone () { }


public static function getInstance()
{


if (!isset(
self::$database)) {
self::$database = new Database();
}
return self::$database;
}
}

I have been using the Singleton for awhile now and ran into unexpected results with an app recently.

I most often used the singleton to get an instance of a class throughout several parts of a framework I wrote. No other method other than the singleton instance was static.

When I used it, it would return the wrong results. For example, an authorization controller I wrote, upon checking if a used was logged in ( a simple bool ), would always return false. Then I tried this...

which fixed the problem. If it helps, I also had a factory method for chaining and what not. I know the singleton was setup right to return the instance, I just don't know what was causing the issue and still haven't figured it out. Maybe authorization was just a bad idea for a singleton, but either way its working quite well now.

It's hard to tell without seeing the entire class, but you must have had an error somewhere in the implementation of the singleton - it should simply return an instance of your object from a static property where the instance is being held. Outside of generating the instance, it should have no effect on the object or its methods whatsoever. If the object was not responding properly, there was possibly either an error in the object, or in the way it was generated.

One thing that I usually do and, which in case of this example won't change anything is instead of instantiating the class with its classname I instantiate it with "self":

Instead of doing this:
I do this:
Then you don't depend on the classname and if you ever change its name you don't have to also go through the code.

I have a another example of signletone in php for a connection to a database using myqli for anyone who likes use this.