Factories
The finer points of the different factory design patterns has always escaped me, so I decided to look it up recently and found this rather helpful stackoverflow answer. I thought I’d summarise what I learnt below (all diagrams were generated using yUML).
A factory design pattern in the most general sense is one that entrusts a class or object with the creation or instantiation of another object. Commonly, the class or object that does the creating is called the Factory object and the object being created is called the Product object. Bare this in mind when viewing the diagrams that follow.
Static Factories
A Static Factory is a class that defines a static method that generates various subtypes of a Product. It accepts an argument to determine which Product subtype to generate (shown as a string here, but it could be just about anything). The static factory does not need to be instantiated in order to generate a Product subtype. In some languages, Product’s constructor is typically made private so it can only be called within the Product class and thereby prevent the factory from being bypassed.
If the system is later updated and a new Product subtypes is added, the static factory class must be updated to include the new Product subtype.
NB: I’ve used underscore here to indicate a static method as yUML doesn’t appear to be able to underline text.
Simple Factories
While static factories define a static method for generating Product subtypes, a Simple Factory is a separate class that defines an instance method to generate instances of Product subtypes. Again, the method typically accepts an argument to indicate which Product subtype to generate. The Product constructor’s visibility can be restricted to package if the simple factory and product are packaged together.
The simple factory class must first be instantiated before it can be used to generate a Product instance. Similar to static factories, if a new Product subtype is added, the simple factory class needs to be updated to include it.
Factory Method
A Factory Method class introduces another level of abstraction by defining a Factory Method interface that includes a method to produce Product subtypes. Concrete factory method classes implement this interface and define the factory method to generate Product subtypes related to its (the concrete Factory Method class) own type. Again, you need to create an instance of the concrete Factory Method class before you can create an instance of a Product subtype.
If a new Product subtype is added, each concrete factory method class that needs to be able to generate the new Product subtype, will need to be updated.
Abstract Factories
The Abstract Factories is useful when when you have several Product objects that are related conceptually, but not through inheritance. It adds a factory method to the interface for each Product object (each of which has its own set of Product subtypes). It can be thought of as overlapping two or more Factory Methods on top of each other.