Factory implemented with static method

Question

I have seen an implementation of Factory using static methods. Something like this:

public class MyFactory {
    public static Product1 createProduct1() {}
    public static Product2 createProduct2() {}
}

p1 = MyFactory.createProduct1();
p2 = MyFactory.createProduct2();

I am not sure whether I can call it Abstract Factory, but that is not the question. What I understand about Abstract Factory is that it gives us the flexibility to change the product families easily.

Factory factory = new MyFactory();  // might be a global or Singleton
p1 = factory.createProduct1();
p2 = factory.createProduct2();

And if I want to change from MyFactory to YourFactory then only one line is required to change. I can also change that in run time. But is it possible if they are implemented as static method? I need to change all the calls to static factory. And also need to use if-else checking in every places if we want to decide at run time.

p1 = YourFactory.createProduct1();
p2 = YourFactory.createProduct2();

So what is the benefit of implementing factory using static methods? Are not we loosing the main flexibility? What have I missed here?

Please note that no specific language is assumed. Any help is appreciated.

Answer 1

With static methods like that, you get some code reuse but that's about the extent of the benefit. It essentially reduces the oo pattern to a procedural paradigm. The big thing that you miss out on is changing your implementation at runtime based on context.

A singleton is only slightly better. It enables you to write your logic normally with member variables (state) and then just make a couple of tweaks to turn it into a singleton. Let's say your were doing some instance pooling in your factory, a singleton might be a good fit there. You still miss out on context though.

The most flexible pattern is to use dependency inversion, meaning your class depends on a factory abstraction and doesn't know or care if it's a singleton or not. This enables you to consider the context when supplying the concrete factory to use.

Answer 2

I was about to say I see no benefit of using this factory over instantiating your objects through new Product1(), etc.

However, that is not quite correct. You can choose an implementation for a base class when you use such a factory, and that may be the reason they implemented it. For example, the createProduct1() method can be implemented as return new JumboProduct1(); where JumboProduct1 is derived from Product1, and the rest of the code will be isolated from such a policy decision. Not very flexible, but it would get the job done, I suppose.

I will watch answers to this question to see if there are other uses for such a setup, because I cannot think of anything else at the moment.

Answer 3

There are no benefits of Abstract Factory here. Only if that method is a Builder - you can encapsulate some conditional logic into createProductX() methods.