Photo by Nicholas Barbaros on Unsplash

When we need a single instance of an object, of a specific class, to exist in our application, we use the Singleton pattern. Now, the pattern itself is frowned upon in some circles and is seen as an anti-pattern.

  • The introduction of global state into the application.
  • The previous point can make unit testing hard if your singleton changes some global state.

The Code

The Approach

$factoryOfDobClass = function () { return new ClassThatMarksDateOfInstantiation; };
public function __call($method, $args){return call_user_func_array([self::$instance, $method], $args);}

Singleton Pattern and Dependency Injection

You probably noticed that singletonize() just returns an anonymous class. That is, we can’t use the original class directly as it does not contain logic to ensure that there is only one object. This means that a coder calling new on the class of interest will get a new instance. That’s definitely not what we want. Dependency Injection (DI) comes to the rescue there. Stated simply, DI is an implementation of Inversion of Control. Or as read on Wikipedia:

$this->container->singletonize('DobClass', $this->factoryOfDobClass);
$dob = $this->container->get('DobClass');


The Singleton [anti-]pattern is one of the first we, as developers, learn. It is easy to understand. Despite the pattern’s issues with SRP violation, global state access or hidden technical debt, when properly understood the pattern can be valuable. Indeed, what singletonize() gives us is the ability to separate multiplicity concerns from the behavior, hence responsibility, of the class. Used with dependency injection and singletonize(), the Singleton pattern becomes a safe and valuable tool for the software engineer.

Solutions Architect and Coder

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store