Development

Static Factory methods aka named constructors

Static Factory Methods aka Named Constructors

Create Object Instance

We have many ways how to create an object instance. You can use “new” word, use a Factory or Builder Method, Inject it using IOC Container.

Sometimes we have a situation where an object can be initialized in multiple ways, mostly based on the parameters passed in. It is still the same type of object, therefore there is no need to inberitance and split it into multiple parent-child classes. The solution can be to create multiple constructors.

In many languages like Java, C++, etc we have something called method overloading. But let’s focus on PHP, which doesn’t contain such feature. How we can handle such a case?

Named Constructors 

The name of this pattern is most popular in the PHP world. Its original name is Static Factory Pattern and it is a great solution to this problem. The basic idea is that we hide the __constructor method by making it private, but instead, we create several methods that will create an instance of the object. I must admit that the basic idea is quite similar to the Singleton pattern, with a few differences. We have multiple initialization methods and inside them we always create a new instance of the object (calling the private constructor).

To details

The main thing here is that those multiple initialization methods should also be properly named. The name should present context or intention of our object initialization.

As an example, let’s consider how such a class can be improved to avoid so many IF statements. And Several other problems associated with this case. (Hopefully you’ll spot at least two):

Solution 

Below is the code that demonstrates an example class. I think the intent will be quite clear and needs no further explanation.

This way we have small closed blocks, and we are sure that at least one of it will be called to create the object instance.

Wondering about those two issues from initial code?

This code which is presented before refactor contains at least two main issues: 1. From outside, when you want to create the object, the params intention is not quite clear. It doesn’t say that a) you have to set at least one param b) you shouldn’t set multiple params 2. There is a risk, that no params will be set – it’s not covered whith the if-else statements, and you can’t predict the results of it.

Subsequent articles

  • Static Factory Methods aka Named Constructors: Read more…
  • Improving conditions clauses – few small things with hudge impact: Read more…