Basic Design Patterns – Singleton and Factory
Design patterns are the techniques programmers use for solving some sort of programming challenge using objects. There are many, and I’d encourage you to learn more than what these videos have space to teach. But out of them, 2 of the most commonly used are called Singleton and Factory.
The simplest of these is the Factory pattern, here’s one way to represent it:
{show code example}
Like I said, very simple – a Factory pattern exists whenever you use one class to create another. But it can be extremely powerful. Essentially, it has your code avoiding the new statement for certain types of objects, and instead relying on a specialized class to build them for you.
The purpose of the Factory pattern is to make your job as a programmer simpler. The example I just showed you is sort of a silly one. With objects that simple to create, there’s not much point in using the Factory pattern. But this technique becomes very useful when the constructor for an object takes many different, complex arguments. Instead of looking up all the information needed to construct one of those objects every time, your Factory class builds them for you and sends them back to your scripts ready to use.
By employing the Factory pattern, you create a situation where one part of your code doesn’t need to know about what another part of your code does. And that’s when object-oriented programming gives you the greatest benefit. By making different parts of your code work without any need to understand what another part does, you can more easily expand functionality in one area without having to completely rewrite others. That also makes it easier to debug, and more effectively tackle a project as a team.
The next design pattern I want to look at is the Singleton, and it gets its name from the fact that, when you use this pattern, there can only be one instance of your class running at any given time.
{show example Singleton}
The basic way it works is you have a constructor that’s declared as private, and a private static variable, usually called $_instance. Then, you have a public static method called ‘getInstance’.
Because the constructor is private, you can’t call $obj = new Singleton() anywhere outside the class itself. When you want to get an instance of Singleton, you go through the Singleton::getInstance() method.
The getInstance method, since it’s on the Singleton class, is allowed to call ‘new Singleton()’. So, when you put in a call to Singleton::getInstance() it first checks to see whether self::$_instance is null or not. If it is, it says ‘self::$_instance = new Singleton();’. Next, it returns the value in self::$_instance.
And that’s really all there is to it. Since there can be only one instance of Singleton at any given time, you know that any change you make to any property on it will be still be reflected if you access it anywhere else.
Technically, in this example there’s nothing stopping your code from cloning a Singleton, but if you wanted to prevent that too, you could just create a private function called __clone. __clone is one of the magic methods php provides, and just like __construct can be used here to prevent an outside call to the ‘new’ statement, __clone can be used to prevent the ‘clone’ statement from working.
So, I created a very simple test script to show the Singleton in action:
{show test script}
And here’s the output from that:
{show output}
Notice, I call the ‘getInstance’ method twice, but the objects in both cases are actually the same. Even though I set the ‘data’ property on $singleton1, when I display the contents of ‘data’ on $singleton2, the value shows up there.
So why would you want a Singleton? Well, if there’s code you want to make sure gets run just once in setting up an object, but then have access to the results of that code all throughout your script, Singleton is a pretty good way to handle that situation.
Later on, when we look at setting up an object-oriented login system, we’ll employ a User class that’s a Singleton. We only want to check a user’s session one time per page load, so by putting that into the constructor of a Singleton, we can accomplish that. But then every time we need to get a user’s information, it will be available without having to re-check their session every time.
January 24 2010 12:31 am | Schmategories