Here’s a friendly dip into design patterns. It’s based on the ideas presented by the gang of four.
The Abstract Factory and Factory Method design patterns are similar in that they both decouple the creation of an object from its code. While Abstract Factory is used to create families of objects, the Factory Method is geared towards deferring creation of objects to subclasses in order to improve reusability of code among other things. Because of this they differ in many ways in the structure and use of classes (class relationships).
Abstract Factory
The Abstract Factory design takes a part of a program and encapsulates it (lets say the classes of objects determining look and feel). If we had different themes- tundra, nihilo, etc., the Abstract Factory would make it so that we could define which theme we wanted to be active at the outset of the program. That way we would have the flexibility to easily change from one to another.
The Abstract Factory class declares the interface for creating objects etc, but it’s the concrete classes that actually implement them. That ensures the interface stays uniform across all concrete subclasses. For example to make a button, the abstract factory would have the make_button() interface. However the individual themes would have code that would actually build the button to the theme’s specification when make_button() was called. That way none of the other classes have to know which theme was actually instantiated.
Factory Method
The Factory Method similarly defines an interface for creating objects. However the difference is that it lets subclasses decide how to instantiate.
For example, say we have an object that needs a window to contain it. As part of the constructor we could just write: new window(). The problem is that if I wanted a more flexible scrolling_window, I would have to write an entirely new class with: new scrolling_window() in the constructor to achieve the simple difference.
The Factory Method solves this by writing the class with functions that create the new object themselves. Instead of writing: new window(), I create a hook for subclasses, like a function create_window(). If the parent is an abstract class, create_window() will be blank for the concrete children to fill with things like: new window() or new scrolling_window(). If the parent isn’t abstract it will have a reasonable default value (like new window()) to be overwritten by application-specific children. In this way I maintain the interface while the subclasses instantiate with what they need and minimal extra code.
Compared
The structure and class relationships are similar in the sense that often they use subclassing to move from abstract classes to concrete classes in order to create flexibility. They maintain interfaces and they encapsulate the different implementations.
They differ in that the Abstract Factory is usually implemented as a Singleton which would create a family of objects. It’s usually set while the application loads and not changed afterwards. It is good for big groups of changes that need to happen based on which OS you’d be using, which theme, etc. It’s not to give flexibility for creating objects on demand, since usually once one concrete factory is chosen, it won’t be changed. An example diagram would be:
The Factory Method on the other hand isn’t usually a thematic group or a Singleton. Instead it is an implementation that allows flexibility in object creation. Thus it doesn’t necessarily create a family of objects as much as it gives a family of possible customizations. It isn’t set during loading like the Abstract Factory is, so any of its children can be instantiated during execution and interact with other objects. An example diagram here is:
