tl;dr Patterns, 20 Years Later: Factory Method is a pattern that is often called by a simpler name hinging on the word “Factory”, a la “the Factory pattern” or somesuch. The GOF language actually has
tl;dr Patterns, 20 Years Later: Factory Method is a pattern that is often called by a simpler name hinging on the word “Factory”, a la “the Factory pattern” or somesuch. The GOF language actually has two patterns which each could qualify under that moniker, this one and the Abstract Factory, depending on the intent and the desired consequences.
We want to define an interface for creating an object, but let something (usually subclasses, but not always) decide which object type to instantiate. Factory Method allows a class to defer instantiation to subclasses.
A class can’t anticipate the class of objects it must create. In other words, either the system is deliberately designed to be “open”, allowing types that weren’t known at the time of the framework’s creation to be created (which is the case in most application frameworks, for example), or the system is deliberately drawing an encapsulatory barrier between the class representing the abstract type and the implementations, in order to help facilitate better decoupling. Most systems or platforms that support some notion of “plugins” are in the former category, although often at a binary level of interoperability, rather than a source-language level of interop. (Most Component Object Model (COM) developers will remember CoCreateInstance, for example, which is the classic example of a Factory Method.)
A class wants its subclasses to specify the objects it creates. The defining type doesn’t know the exact subtype to create, but it wants some level of relationship to itself, so it will ask that the actual construction be done via a subclass. This way, clients can still reference the Factory directly through the base interface/class surface, and don’t have to worry about any of the subclass details—all knowledge is funneled through the base interface.
Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate. But if there are more than one subclass, how do clients know which one to use? This is where the base type can still provide value to the system—it can examine the request in some fashion, determine what the appropriate type of subclass to use, and then delegate all further construction knowledge to the subclass.
Create a hierarchy of Product types that vary by inheritance, and a corresponding hierarchy of Creator types that provide a method by which to construct instances of Product (sub)types by deferring the construction logic to the Creator subtype.
Factory methods eliminate the need to bind application-specific classes into your code. Because clients only ever deal with the base Product type interface/surface area, clients can remain entirely ignorant as to the exact nature of the Product with which they are dealing. This is particularly important in “open” systems, in which the complete set of possible Product types is not known, allowing third-parties to participate as part of the system.
Clients (might) have to subclass the Creator class just to create a particular ConcreteProduct object. In the classic GOF pattern, subclassing was seen as the principal way to customize the FactoryMethod implementation. This is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution. This can be mitigated in some cases through the use of functions, but doing so would lose some of the other benefits of subclassing (such as locality of related features in a subclass).
Provides hooks for subclasses. Creating objects inside a class with a factory method is always more flexible than creating an object directly. Factory Method gives subclasses a hook for providing an extended version of an object.
Connects parallel class hierarchies. In most of the GOF examples, the factory method is only called by Creators. But this doesn’t have to be the case; clients can find factory methods useful, especially in the case of parallel class hierarchies. The GOF show an example of graphical shapes (Figure serves as a base to LineFigure and TextFigure), and each has different “manipulators” for when being manipulated (dragged, resized, etc) in a graphical editor; therefore, Figure defines a CreateManipulator() method, which creates a Manipulator-derived type. LineFigure creates a LineManipulator instance, TextFigure creates a TextManipulator instance, and so on. In this way, the FactoryMethod connects the Figure hierarchy to the Manipulator hierarchy in a fairly natural way.
Creator may or may not have additional responsibilities. In the classic GOF hierarchy, Creator has little by way of responsibility beyond that of creating Product instances; however, in several of their examples (including the Figure/ Manipulator example mentioned above), it is implicit that the Creator has more than 