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.
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.
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.
There are no benefits of Abstract Factory here. Only if that method is a Builder
- you can encapsulate some conditional logic into createProductX()
methods.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With