It's common place for factory classes to be static, and factory methods to be static also.
Did the GOF in the Design Patterns book ever stipulate that factories and their methods MUST be static in order to meet the strict definition of the pattern?
Is having factories+/methods static just a consequence of the pattern? state data is not normally maintained by the factory class, so they're normally static.
I don't believe there is such a thing as a "strict definition" of a pattern. By their nature patterns exist to capture the essence of a problem which crops up time and time again in software and outline how a solution might look.
Specifically with the Factory pattern, no, there is no requirement that the factory methods be static. The essence of the pattern is that you have one object which is responsible for creating instances of another class. How you do this is really up to you, although a common way, as described in the pattern, is to use a static method on a class. However, we have a factory mechanism in one of our systems which is actually two-stage. You use a static method on a class to create the factory object, which can be configured to choose amongst a set of implementations, and then use the factory object to stamp out instances of the object that you need to do the real work.
Also consider the implementation of the factory pattern in a language which does not have static methods. For example, in Scala you would use an object instead of a class. Although the behaviour of this is a lot like using static methods on a class in Java, the nature of the implementation is quite different.
No, factories can hold state. It depends on what is needed.
I'd suggest that making is static seems good choice in the first instance - hovewer the moment you try to unittest statics you tend to run into problems.
Steer away until you specifically need them.
No, factory class by default shouldn't be static. Actually, static classes are not welcomed in OOP world since they can also convey some state and therefore introduce global application state. If you need only one factory object to be present, you can control it's creation through singleton pattern.
In case of factory method - it is ok to keep it static (actually there's no other reasonable way to go :)).
It depends on your needs. I generally prefer a static method for creation:
SpaceShip spaceShip = SpaceShipFactory.create();
Also, Java uses static methods for Factories in most cases.
Calendar calendar = Calendar.getInstance();
But if we're gonna create multiple instances from the same factory. Maybe we can prefer non-static way for it. We need some stateful fields as the Algorithm for this purpose.
SSHKeyFactory factory = new SshKeyFactory(Algorithm.RSA);
Key client1Key = factory.createKey();
Key client2Key = factory.createKey();
...
Usage of Static Method is not related to any design pattern. It is the choice of either we use a Class level or an instance level method.
Factory class does not requires to maintain any state. So that normally we go for Static method . If it really requires a state, then we create an object to the class and set state to the object. This time we might choose either static or instance method.
I guess that my BlueCarFactory and my RedCarFactory both have a method createCar. It's just common sense to reuse the actual creation method by parameterizing it. One would then create a CarFactory(blue) and a CarFactory(red). This means that the CarFactory object needs a member variable to store the color of the produced cars.
Concluding: it makes no sense to make the method of a Factory class static. It does make sense to create a singleton Factory object.
There are two patterns in the GOF book with "Factory" in the name. Due to their very nature they both exclude the possibility of making the methods static.
Abstract factory - your create interface for a factory that concrete factories implement.
Factory method - you create a base class with an abstract method (or empty implementation), that is supposed to create some objects and you implement it in subclasses.
No place for static context here really.
A lot of people call static methods that create objects "factory methods", but this is completely incompatible with what the GOF book defines as "factory method" pattern.
