In fact, I strongly believe that every concept (ok, most ) have benefits and drawbacks. The case of the singleton for me is easy: it depends.

So what’s wrong with that pattern?

Some people claim that the Singleton pattern is a sign of bad software design. They say the Singleton can be used as some kind of global variable. Well, that’s true, sometimes. But the Singleton can be used otherwise than a global variable holder. Actually you have to differ between your programming language before thinking about a good or bad usage of the Singleton Pattern.

How to implement the Singleton pattern in PHP

PHP is a scripting language, it’s actions are performed by an interpreter. It doesn’t support multiple threads like Java or Ruby does. This is very important later. But first, lets create a singleton in PHP.

class MySingleton {

    private static $instance;

    private function __construct() {}

    public static function getInstance() {

        if(self::instance == null) {

            self::instance = new MySingleton();

        }

        return self::instance;

    }

}

How does this work? You create a static variable in a class. If one calls getInstance() for the first time, a new object is created and stored in the static variable. If you call the method again, you’ll get exactly the same instance you created with the first call. This object – since it is static – will stay until your script has ended and the complete request is processed. You see, why the singleton has it’s name. It’s only one object created and used for all the time.

And to keep this behaviour, you just have to put your constructor private – nobody else than your getInstance method should be allowed to create this object.

How to implement a Singleton with Java

Now you have to think about some more issues. Since Java supports multithreading you have to think about more than just creating the object and returning it. First, we’ll see how a pure PHP programmer would create the singleton with Java syntax.

public class MySingleton {

    private static MySingleton instance;

    // Again - just MySingleton is allowed to construct this object

    private MySingleton() {}

    public static getInstance() {

        if(instance == null) {

            instance = new MySingleton();

        }

        return instance;

    }

}

OK, now think about two threads which call getInstance() at the same time, and imagine nobody has done so before. Both threads would enter getInstance(). Chances are good that Java helps you even with multiple processors (it should do, cause Suns Sales Managers sell Java as a simple to use language ). In that case, one thread would go on to create the MySingleton object, while the other one will jump over it and return the instance.

You have to ask the question, does this really work? Cause at which point of time is instance not longer null? The answer is, if you create the object headers, the instance variable is not longer null. That means, that a second thread could overtake thread one and work on an instance which is not really created (just the have of it)! Something unexpected will occure and even if your customer will claim about an error, you probably will never have the chance to find it.

So what now? We have to make sure that:

a) two threads are not creating a MySingleton object at the same time
b) one thread doesn’t work on the object while it is still under construction

Some programmers start something like this:

public class MySingleton {

    private static MySingleton instance;

    public static getInstance() {

        if(instance == null) {

            synchronized(this) {

                if(instance == null) {

                    instance = new MySingleton();

                }

            }

        }

        return instance;

    }

}

Please note the synchronized block above. It keeps care that only one thread can execute the code for creation at one time.

Is this the solution? No. Even in that case it can happen that Thread 1 locks everything correctly for creating the object. But if Thread 2 comes at a bad time, it will ask the outer instance == null check and again it could return an unfinished object. The synchronized block just helps with one problem.

Actually there is only one 100% solution. Create the necessary object while class loading.

public class MySingleton {

    private static MySingleton instance = new MySingleton();

    public static getInstance() {

        return instance;

    }

}

This is a solution PHP programmers cannot have since PHP doesn’t support to create objects like this. But for the Java programmer it’s the only way to make object creation work. And yes, sometimes it’s not possible to go this way. But that’s another story.

Singleton Lifetime

You should know about another difference between Java and PHP Singletons. In Java, the static keywords makes the variable available at a class level, not at object level. This means it follows you as long as the JVM is alive – from programm start to programm end, and in case of an enterprise or an eai server, this can take a long, long time.

For a PHP programm it’s the same – from programm start to programm end. But in PHP words this means the time when an HTTP request arrives and script execution begins till the end of the script has been reached. After a request, the singleton is gone, dead, and you’ll have to create it again, with the next request.

In human words, this means that a Java singleton probably lives for days, weeks or even months and the PHP singleton just for less milliseconds.

The Benefits of Singleton

Well, benefit is: you have to create only one object of an class and can use it over and over again. This is cool, since creating an object takes usually a long time in the interpreter or in the virtual machine. Cause of this, old programmers often say object orientation is slow. Meanwhile everything is faster and in most cases you don’t have to care bout this anymore.
And this is where critic starts: people say, you could misuse the Singleton as some kind of global variable store. This comes often from PHP programmers, who think about that code:

class MySingleton {

    ...

    public $bla = "blubber";

    public static function getInstance() {

        ...

    }

}

In this case, you can have the variable $bla available all over your code. Just do a:

MySingleton::getInstance()->$bla;

Is this good? No. Of course not. If you just want to store something, go ahead, use $GLOBALS or a similar global available variable. Same goes to Java. There are no global fields, but you can create some similar with System properties.

But Singleton will have more the worth if the singleton object has some methods you can operate on. Imagine that singleton object trys to reload a configuration.

class MySingleton {

    ...

    public $bla = "blubber";

    public function loadConfiguration() {

        // code to load xml file

        $this->bla = getValueFromXML();

    }

    ...

}

This would make it possible to reload the config at runtime. Even date formatting etc. would be possible at runtime.

Basically said, an object which provides methods is worth something. It’s not to bad to do so. But a more cool benefit is if you have a stateless singleton.

class MySingleton {

    ...

    public function doSomething($bla) {

        $bla = $bla / 2;

        return $bla;

    }

    ...

}

Imagine doSomething() does some complex things with $bla. You don’t need to store the result in the MySingleton object. It will returned. Since there are no object variables available, this object is stateless. And there is really no need to create multiple objects just to perform some operations on $bla.

But why should one consider to create an object if he can do this in a static way, you ask. Static access to methods is not very flexible. Think on AOP, where objects wrap other objects and prevent you from calling a method directly. This wouldn’t work. That’s just one example. There are others: maybe you want to choose at runtime, which implementation you use to create this task. In a static context you would have to change your implementation, in an object context you could use a factory and a strategy pattern to switch. This is way more flexible.

Drawbacks of the Singleton pattern

Yes, of course there are several. Think on the global variable thing. It’s true, imagine you have one thousand of Singletons, all keeping care of their own little states, read within the application from a million of places. Not very good. Esspecially with PHP you cannot easily find out where those variables are called. In Java you have some good shortcuts in your IDE.

But we know now, that a Singleton is meant for reducing object creation time and not for state sharing. Next drawback is more significant, since the first one is a mistake just inexperienced programmers do.

Problem is, if you create a Singleton it will stay one forever. If you need to make multiple objects of your class, you have to write code for this. In small projects this is not such a big issue, but in a 100.000 lines of code project it is. There are other patterns like Prototype or Factory which could be useful suddenly and we would have to write code. This is a risk.

The solution is to create this Singleton not by code like we did above. Use a framework for creating your objects. In PHP you PIWI and the BeanFactory at your side, which helps you with constructing singletons (and injects the objects in other objects – Dependency Injection, see the previous article).
In Java you can use Spring for this. Spring is the big inspiration source for PIWI (regarding object creation and dependency injection) and widely used. Besides Spring there is Google Guice and PicoContainer too, which provide similar stuff.

Finally

There is no need to say Singleton is good or bad. It’s neither. It’s just a pattern. A Singleton is just as evil as you misuse it, and just as glorious as you identify it as fitting pattern to a specific problem.

In my projects I use a Singletons sometimes for configuration. I don’t think it’s bad behaviour. If I don’t have one thousand of this object in my System, it’s OK. More often Singletons are used as some kind of worker classes, just here for doing complex stuff with storing a state. They help me not to waste memory. And due Singletons are objects I easily can extends them via aspect oriented programming – perfect!

Design Patterns – all just theory?

If students make their exams and come as junior programmers to my projects, they often believe a design pattern is something to eat. Or something theoretical. Or simply a joke. I usually start with explaining how to use it and such, but at the first glance it seems to abstract to them. Later, with the expierence, comes the joy.

This is true for patterns like Singleton or Factory or maybe Model-View-Controller. Coming to Dependency Injection – which is not read very often in Books about good software design – most people NEVER have joy. In this kind it behaves like the Proxy pattern. One really cannot use this out of the box. I mean, a singleton can be implemented within minutes, and it does what it does. But Dependency Injection? It’s more a concept of software design than a design pattern. Can you implement a singleton? Yes. Can you implement Dependency Injection? No, of course not. Having that said, the joy and the power comes when you are using a fitting framework which supports the design pattern. Like Spring. Or PIWI, in the latest trunk version. Cause we PIWI-folks simply have stolen much of the ideas of Spring and now use it not only in Java, but in PHP5 too.

What’s all about it?

Basically Dependency Injection simply says: don’t make a class dependent from another, inject the dependency. So what? some will say. But it’s simple. Imagine the following PHP lines:

class Car {
   private $driver = null;

   public crash() {
      $this->driver->saySomething();
   }
}

You see, there is a private member called driver in the car class. If your use case is that each car is a driver, it’s quite easy in most cases. Just fill the member in the constructor. This is, what most people do. This makes $driver nullsafe.

class Car {
   private $driver = null;

   public __construct() {
      $this->driver = new Driver();
   }

   public crash() {
      $this->driver->saySomething();
   }
}

OK. From this point on the class Car depends on the class Driver, cause you need the Driver class to instanciate Car. After you did that and all works well, your boss looks round the corner and tells you that we need to distinguish between female drivers and male drivers. He is sorry for saying that so late, but it’s like this. Cause if you call the new method crash(), a female driver would simply say:”you crashed me!” and a male driver would say something like:”guy i have a gun!”. And, that’s the point, your client A just wants male drivers in their systems, while client B just needs female drivers.

People start doing:

class Car {
   private $driver = null;

   public __construct($client) {
      if($client == "A") {
         $this->driver = new MaleDriver();
      } else if($client == "B") {
         $this->driver = new FemaleDriver();
      }
}

   public crash() {
      $this->driver->saySomething();
   }
}

All is good. But what if you need to port the system for somebody who just let childs drive? Or people with glasses upon their noses? In fact, we had the requirement to create several modules for several clients – customization. Yes, the example above with male and female drivers is not the best, but I am sitting in a car while typing this.

Problem on the approach above is that you need a new if else if you ever have more Driver types than above. And you have to put this in class where such dependencies exist. Maybe it’s not pretty much, but in our case we had about 20 modules – without customizations. I really was afraid before such a switch.

Dependency Injection for the solution

As I allready told you, we had Spring and Java 6 in our system. But we ported dependency injection to PIWI. And if you are using one of these frameworks, you know that both heavily use XML. Imagine you could say in an XML which driver you want to use. More better: you really would define an interface for all the driver classes and would make sure that you operate on that interface only.

See this:

interface Driver {
   public saySomething();
}

class FemaleDriver implements Driver {
   public saySomething() {
      echo "You crashed me!";
   }
}

(imagine something similar for MaleDriver).

You could do something like that:

class Car {
   private $driver = null;

   public __construct($driver) {
      $this->driver = $driver;
   }

   public crash() {
      $this->driver->saySomething();
   }
}

Isn’t your code much cleaner now? You know, if else means death to object orientation! This way your Car class doesn’t depend to MaleDriver or FemaleDriver. In case of PHP5 it just depends on an untyped object. In case of Java it depends on the Interface Driver.

By the way: you can force types in PHP5 (in some level of course). You could write the constructor like this:

public __construct(Driver $driver) {
   $this->driver = $driver;
}

This forces the caller to put an object inside which implements the interface Driver. And this in fact is the way you should go! And this is all about the Dependency Injection pattern. It says, make your classes dependend on interfaces, not on classes.

So, isn’t it nice? But how do you decide to bring your dependency in? This is another point, and this is why I said you have to check out Spring or PIWI for this. The example above is working gorgeous, but if you don’t find a mechanism to bring your dependencies into the game, all is lost. I promised XML like Spring does, and here it is: PIWIs XML file for Dependency Injection in PHP.

<bean id="xmlPage" class="XMLPage" scope="request">
   <property name="contentPath" php="$GLOBALS['PIWI_ROOT'].CONTENT_PATH" />
   <property name="siteFilename" value="site.xml" />
</bean>

<bean id="siteSelector" class="SiteSelector" scope="request">
   <property name="page" ref="xmlPage" />
</bean>

We call our objects beans, like Spring does. It’s Spring-Beans in Spring, but PIWI-Beans in PIWI. We are shameless. First, look at the bean definition with the id xmlPage. You give it a class and a scope, and some properties.

Basically, PIWI (and Spring too) creates the objects for you. That has many benefits. I will write an blog article why instanciating objects yourself is sometimes a bad idea some day. However, PIWI makes an object and stores it in our context, the BeanFactory. It’s stored under the id xmlPage, and you can get the object manually if you call:

$xmlPage = BeanFactory::getBeanById('xmlPage');

This brings you the ready bean. Additionally you tell the BeanFactory that it should set the property “siteFilename” to “site.xml”. And one line above you even give it an PHP expression. After PIWi made the object from the class XMLPage, it checks if a member variable is accessible named siteFilename. If it isn’t it looks if there is a method called setSiteFilename($o); or siteFileName($o). If PIWI found that method, it calls it with the value.

This is all done by reflection, which has been shipped with PHP5. No dependencies to other libs, no problem. Just plain PHP5. Same goes to Java. Plain Java. No Magic. Just some reflection.

If you would have called this line instead of the one above:

$siteSelector = BeanFactory::getBeanById('siteSelector');

the BeanFactory would have created the siteSelector bean. If you look into it, you see this:

<property name="page" ref="xmlPage" />

If the BeanFactory gets aware of this (and it does!), it will look in the context for a PIWI Bean with the ID xmlPage. If there isn’t one, it will try to create such a bean. Same rules as above. After creation of xmlPage it will be set into SiteSelector’s setPage($xmlPage) method.

And now imagine how your boss would love it, if you tell him that such a customization is just a matter of some XML?

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

Everthing done!

For the sake of completness – what do we mean with scope? Well, scope is in which scope your object lives. Defining request means, the we create maleDriver only once while the whole request. If you define another class which needs maleDriver, it would get – exactly the same -. This is, what some people call a Singleton in PHP. But Singletons are worth an own Blog entry, since some people – esspecially who have just written code with PHP and not for Java Enterprise Systems – say, Singletons are evil. Well, they are not. If developers are not thinking while coding, that is evil You can misuse everything, if you want to.

Here is another example for using the driver more than once:

<bean id="maleDriver" class="MaleDriver" scope="request" />
<bean id="femaleDriver" class="FemaleDriver" scope="request" />

<bean id="car" class="Car" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

<bean id="truck" class="Truck" scope="request">
   <property name="driver" ref="maleDriver" />
</bean>

In this case, only the same instance of maleDriver makes it to the truck and to the car. Decide yourself if this is your usecase. In the MaleDriver class are no states defined – so one object is enough.

OK – Dependencies are out. Instanciation is out of the code too. But is this the whole benefit? Not really. This stuff makes it possible to create dynamic proxies and use aspect orientation, even with PHP. And be sure, PIWI will have features some day. And Spring still got this cool stuff. But that’s another story.