Thing that all three have in common is that they are responsible for creating objects. The calling class (which we call the “client”) wants an object, but wants the factory to create it. I guess if you wanted to sound really professional, you could say that factories are used to encapsulate instantiation.
So what’s the difference between a simple factory, a factory method design pattern, and an abstract factory?
- A Simple factory is normally called by the client via a static method, and returns one of several objects that all inherit/implement the same parent.
- The Factory Method design is really all about a “create” method that is implemented by sub classes.
- Abstract Factory design is about returning a family of related objects to the client. It normally uses the Factory Method to create the objects.
You can checkout the working project from my git hub repository, here is the link : https://github.com/premaseem/designPatterns/commit/94cdd85ac5f7080fb1be03dc885d6a6dc3b1ad8c#diff-d41d8cd98f00b204e9800998ecf8427e
Let us take a detailed look in each of them with minute details.
The easiest way for me to remember this is that a simple factory is called directly by the class which wants to create an object (the calling class is referred to as the “client”). The simple factory returns one of many different classes. All the classes that a simple factory can return either inherit from the same parent class, or implement the same interface.
Step One: you call a method in the factory. Here it makes sense to use a static method. The parameters for your call tell the factory which class to create.
Step Two: the factory creates your object. The only thing to note is that of all the objects it can create, the objects have the same parent class, or implement the same interface.
Step Three: factory returns the object, and this is why step two makes sense. Since the client didn’t know what was going to be returned, the client is expecting a type that matches the parent class /interface.
Please note that this is not an “official” design pattern.
The official definition of the pattern is something like: a class which defers instantiation of an object to subclasses. An important thing to note right away is that when we’re discussing the factory pattern, we’re not concentrating on the implementation of the factory in the client, but instead we’re examining the manner in which objects are being created.
In this example the client doesn’t have a direct reference to the classes that are creating the object, but instead has reference to the abstract “Creator”. (Just because the creator is abstract, doesn’t mean this is the Abstract Factory!). It is a Factory Method because the children of “Creator” are responsible for implementing the “Create” method. Another key point is that the creator is returning only one object. The object could be one of several types, but the types all inherit from the same parent class.
Step One: the client maintains a reference to the abstract Creator, but instantiates it with one of the subclasses. (i.e. Creator c = new ConcreteCreator1(); )
Step Two: the Creator has an abstract method for creation of an object, which we’ll call “Create”. It’s an abstract method which all child classes must implement. This abstract method also stipulates that the type that will be returned is the Parent Class or the Interface of the “product”.
Step Three: the concrete creator creates the concrete object. In the case of Step One, this would be “Child Class A”.
Step Four: the concrete object is returned to the client. Note that the client doesn’t really know what the type of the object is, just that it is a child of the parent.
This is biggest pattern of the three. I also find that it is difficult to distinguish this pattern from the Factory Method at a casual glance. For instance, in the Factory Method, didn’t we use an abstract Creator? Wouldn’t that mean that the Factory Method I showed was a actually an Abstract Factory? The big difference is that by its own definition, an Abstract Factory is used to create a family of related products (Factory Method creates one product).
Step One: the client maintains a reference to an abstract Factory class, which all Factories must implement. The abstract Factory is instantiated with a concrete factory.
Step Two: the factory is capable of producing multiple types. This is where the “family of related products” comes into play. The objects which can be created still have a parent class or interface that the client knows about, but the key point is there is more than one type of parent.
Step Three: the concrete factory creates the concrete objects.
Step Four: the concrete objects are returned to the client. Again, the client doesn’t really know what the type of the objects are, just that are a children of the parents.
See those concrete factories? Notice something vaguely familiar? There using the Factory Method to create objects.