Factory implemented with static method

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.

---

taskinoor, Usage of static methods is not recommended in pure OO programming for several reasons.

1. You can not achieve dependency injection with static methods.
2. Writing Unit test cases is very hard and close to impossible. Personally, when I started programming I struggled a lot implementing UT with Static methods.

Having said that there are few benefits with static methods If you are creating a library functions which are tend to remain same at runtime, static methods are a good choice.

Please have a look at the implementation of abstract factory here. I don't think it is required to use "static" methods to achieve abstract factory. http://www.dofactory.com/Patterns/PatternAbstract.aspx#_self1

---

For brevity, using a static method to instantiate objects is cleanest if you have large number of objects to configure. For example, compare:

textObject = new TextUI("Code Example");
textObject.move(50, 80);
textObject.size(100, 200);

and:

textObject = TextUI.make("Code Example").move(50, 80).size(100, 200);

Changing three lines into one makes the configuration cleaner, and the line more portable- only requiring one variable name change. You also benefit from auto-complete with each dot when using the right IDE, making it much easier to write new lines and add new properties.