John Squibb
Using a Singleton to Manage Your Singletons. Wait, What?
I use the Singleton Design Pattern quite a bit, so much in fact, that I needed something to make using Singletons more seamless!
If you're not familiar with the Singleton Design Pattern, or how it pertains to PHP, then I suggest you check it out here.
If you are familiar with the pattern, and like me, have grown tired of adding getInstance() to all your classes and privatizing their constructors, then say hello to the Singleton class, known among his inner circle, as Mr. Singleton.
What's Wrong with the Standard Singleton Implementation?
Nothing whatsoever! But in order to convert your class to use the Singleton pattern, you have to do just that: convert all your classes. That's great if the only implementation you ever intend to use utilizes the getInstance() method. This may be exactly what you want for your database abstraction layer, or your helper classes that aren't static, or one of a gazillion other Singleton-worthy classes.
If you're just trying to cut some overhead by ensuring that your classes only get instantiated once per execution, then the Singleton contract might not be appropriate. Additionally, if you didn't have to refactor all your classes and bind them to the pattern, why would you?
Enter Mr. Singleton.
What Mr. Singleton Does for You
Basically, Mr. Singleton is just a final class that can't be constructed, that sits around waiting for you to request a class. When you do, he assumes the role of elephant, remembering every class you ask him for. If you ask him for it again, he gives you the original instance back, thereby preventing the overhead of additional instances.
Since Mr. Singleton creates the actual object, and remembers its state, all you have to do is ask him for the object, run the methods, and move along. You get all the benefits of the Singleton pattern without the disadvantages of refactoring your code. You can reduce overhead, and leave any preexisting or future code intact!
But enough of the cheesy code personification, let's have an example, shall we?
The Singleton Class
The code is pretty simple, just a few static methods and a member array to hold the instances.
<?php
final class Singleton
{
/**
* Maintains collection of instantiated classes
*/
private static $instances = array();
/**
* Overload constructor
*/
private function __construct(){}
/**
* Manages instantiation of classes
*
* @param $class
*
* @return none
*/
public static function instance($class)
{
//instantiate class as necessary
self::create($class);
//return instance
return self::$instances[$class];
}
/**
* Creates the instances
*
* @param $class
*
* @return none
*/
private static function create($class)
{
//check if an instance of requested class exists
if (!array_key_exists($class , self::$instances))
{
self::$instances[$class] = new $class;
}
}
}
Let's test Mr. Singleton with a sample class and some calls.
You can place the sample code in its own file and include Mr. Singleton, or you can just append it to the same file.
<?php
/**
* Test Taco Class
*/
class Taco
{
private $shell = 'soft flour';
public function __construct()
{
print "constructed\n";
}
public function shell()
{
return $this->shell . "\n";
}
public function change_shell()
{
$this->shell = 'hard corn';
}
}
// Ask Mr. Singleton for a taco.
$taco = Singleton::instance('Taco');
print $taco->shell();
// We'd like to have another taco.
$taco2 = Singleton::instance('Taco');
// Ah, it's the same taco!
print $taco2->shell();
// Change the taco a bit
$taco2->change_shell();
print $taco->shell();
// Can we we have another taco?
$taco3 = Singleton::instance('Taco');
// Dang, it's the same taco.
print $taco3->shell();
Summary
I utilize Mr. Singleton in a lot of my projects, and have grown quite fond of the ability to use him for quick one-off method calls without having to create a new instance of the class I am calling, even if I'm not concerned about redundant instances. Since Mr. Singleton's instance() method returns the instance of the requested object, as shown above in the samples, you can easily chain the first method call right to the back of your request!
Extend and Improve
As always, this could be extended. A lot of Singleton implementations tend to overload additional magic methods, especially __clone(). My goal here is less of a code-by-contract, and more of an ease-of-use approach. If preventing the clone of your objects is important to your project, then by all means, overload the __clone() method.
Suggested Reading
PHP 6 and MySQL 5
by Larry Ullman
Suggested Reading
PHP Design Patterns
by Aaron Saray
Tags: Singleton, Design, Pattern, seamless, getInstance, classes, PHP
Short URL: http://sqb.in/A2tI