Factory Method Pattern

Key Insight

The Factory Method pattern defines an interface for creating an object but defers the actual class instantiation to subclasses, effectively allowing a class to anticipate the objects it must create. This pattern is crucial in frameworks where abstract classes are responsible for managing and creating objects, such as an 'Application' framework that needs to create 'Document' objects. Since the specific 'Document' subclass to instantiate is application-specific (e.g., 'DrawingDocument' for a drawing application), the abstract 'Application' class cannot hard-code which 'Document' subclass to create, leading to a dilemma that the Factory Method resolves by externalizing this knowledge.

To implement this, 'Application' subclasses redefine an abstract 'CreateDocument' operation to return the appropriate concrete 'Document' subclass, thus 'manufacturing' the object without the framework knowing its specific class. This approach eliminates the need to bind application-specific classes directly into the core code, allowing the code to operate solely with the 'Product' interface and support any user-defined 'ConcreteProduct' classes. Beyond this primary benefit, factory methods also provide valuable hooks for subclasses to supply extended versions of objects, such as custom file dialogs, and effectively connect parallel class hierarchies, localizing the knowledge of which related classes belong together, as seen with 'Figure' and 'Manipulator' objects.

A potential drawback is that clients might sometimes need to subclass the 'Creator' class solely to instantiate a specific 'ConcreteProduct' object, adding another point of evolution if not already necessary. Implementations vary: 'Creator' can be abstract with a pure virtual factory method, or concrete with a default implementation, offering flexibility. Parameterized factory methods can create multiple product types based on an identifier, allowing selective extension or changes to products, with considerations for type safety in statically typed languages like C++. For instance, a 'MazeGame' class can define factory methods like 'MakeRoom' or 'MakeWall' with default implementations. Subclasses such as 'BombedMazeGame' or 'EnchantedMazeGame' then override these methods to produce specialized maze components like 'BombedWall' or 'DoorNeedingSpell', without altering the main maze creation logic.