How to get a Singleton right

To answer this question I want to take a step back and take a look at classes implemented as a Singleton. If you look at a typical Singleton implementation, you can divide the methods in such a class into two categories: those that belong to the business logic of this class, and those responsible for creation and access to the single instance of the class. As we can see, these are two different responsibilities. In object-oriented school we learned that a class should have just one responsibility, but nevertheless we make use of a design pattern that mixes two different responsibilities into one class. Why should the class decide how much instances of it shall be created in the application? Actually, the class should not know at all how much instances of it are floating around. It is simply not the responsibility of the class. It should take care that the business logic in the class is performed to the best of its knowledge, and from my point of view a class has all hands full with this task.

On the other hand it is perfectly valid to restrict the amount of instances of a class. And naturally we want to prevent other programmers who use our code to circumvent any such restrictions. Still, why should another programmer care about how many instances of a certain class are floating around in an application (besides performance reasons)? The other programmer should just declare in his code "I need an instance of Logger, and my code will not work without it, and boy I don't give a damn how much instances of Logger are allowed, just give me one!".

Let's get back to responsibilities of a class: a class is responsible for the business logic it contains, and it is responsible to declare the stuff it requires to perform this business logic correctly. By using a Singleton class it declares this dependency in a hidden place. It is not possible from its API to tell that the class depends on another class, if not otherwise stated in some docs. Additionally it should never care how the classes it depends on are created. To sum it up: a class should declare its dependencies explicitly, and this is just done by defining in the constructor "I need this to work properly, and if you do not give me this you will not get an instance of me". Finally some code to illustrate this:

Bad:
class Foo { protected $logger; public function __construct() { $this->logger = Logger::getInstance(); } ... }


Good:
class Foo { protected $logger; public function __construct(Logger $logger) { $this->logger = $logger; } ... }

Here, the second example clearly states that Foo needs an instance of Logger in order to be created. Provided there are proper doc comments (left out to leave the example code short) the API documentation will tell users of Foo that they need Logger in order to get a Foo. Additionally, Foo will be much easier to test because one can inject a mock object instead of a concrete class. As you may have guessed, there is already a name for this style: dependency injection. The shortest explanation for this term might be this one: "Dependency injection means that a class gets the classes it depends on injected as parameters via its constructor or setter methods".

When adhering to the dependency injection principle, you can separate your classes into two categories: those which contain just the business logic, and those which are responsible for creating instances of other classes and stacking them together.* (We've had this before, didn't we?). The good thing about this is that you may stack the business logic classes together in another way and receive a different behaviour - without changing any of the business logic classes at all.

But how do we make sure now that there is only one instance of a certain class? Well, this is the responsibility of the classes that are responsible for creating instances. There you can create an instance of Logger and everywhere another class needs a Logger you pass it this instance. Now you have a singleton** as well, but without the penalty that comes with the Singleton design pattern. One more benefit: if you suddenly detect you need more than one instance of Logger you do not need to change Logger and the classes using Logger now. Just change the code responsible for constructing and stacking objects.

Admittedly, coding this way creates a lot of boilerplate code (which is the code constructing and stacking objects). Writing such boilerplate code is really boring, gets tedious and does not make fun at all. This is a point where a dependency injection framework may help. But that is a story for another day.

One last point. Developers introduced to the topic of dependency injection are often intrigued by the idea but mostly ask the same question: Do I need to pass all my objects required in a deeper layer to the upper layer just so that the upper layer may pass them to its underlaying layer? The short answer to this: no. At least not when implemented correctly. Let's take a house for example. A house has a door, and the door has a lock. When the house requires a lock in order to pass it to the door the design is messed up. The house should just require a door. Whether the door requires a lock or not is total irrelevant to the house. An implementation could look like this:

class House { protected $door; public function __construct(Door $door) { $this->door = $door; } ... } class Door { protected $lock; public function __construct(Lock $lock) { $this->lock = $lock; } ... }

See? The house never needs to know about locks - it just knows about doors. If at all it needs something to do with locks this is exposed as methods on the Door class. (Actually, Door should be an interface, but for this short example it is ok to be a class.)

To answer the question from above: the Singleton Design pattern is used so often because the rest of the code has flaws in its design, it does not separate business logic and instance creation logic right. It is perfectly valid to limit the amount of instances of a class, but to do it right via a single instance in the creation logic the rest of the application must be designed with dependency injection in mind. One could argue that code needs to be refactored as long as there is a Singleton in it.



* An exception to this are classes containing values and data only but no logic - those might be created by the business logic classes using one of the other creational design patterns.

** One could call this the "small singleton" - denoted here with a small s contrary to the design pattern, which has a big S.