Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
Frameworks use abstract classes to define and maintain relationships between objects. A framework is often responsible for creating these objects as well. Consider a framework for applications that can present multiple documents to the user. Two key abstractions in this framework are the classes Application (Creator in the thumbnail) and Document (Product in the thumbnail). Both classes are abstract, and clients have to subclass them to realize their application-specific implementations. To create a drawing application, for example, we define the classes DrawingApplication and Drawing Document. The Application class is responsible for managing Documents and will create them as required--when the user selects Open or New from a menu, for example. Because the particular Document subclass to instantiate is application-specific, the Application class cant predict the subclass of Document to instantiate--the Application class only knows when a new document should be created, not what kind of Document to create. This creates a dilemma: The framework must instantiate classes, but it only knows about abstract classes, which it cannot instantiate. The Factory Method pattern offers a solution. It encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework. Application subclasses redefine an abstract CreateDocument operation on Application to return the appropriate Document subclass. Once an Applicaation subclass is instantiated, it can then instantiate application-specific Documents without knowing their class. We call CreateDocument (located in ConcreteCreator in thumbnail) a factory method because it is responsible for "manufacturing" an object.
This pattern has been used on the following systems: MacApp and ET++ (Weinand, A., E. Gamma, and R. Marty, ET++--An object-oriented application framework in C++. In Object-Oriented Programming Systems, Languages, and Applications Conference Proceedings, pp. 46-57, San Diego, CA, September 1988. ACM Press.) Subclasses of View in Smalltalk-80 specify defaultControllerClass as the factory method that subclasses should override and which returns a class used by the View class, defaultController, to create instances. (ParcPlace Systems, Mountain View, CA. ObjectWorks\Smalltalk Release 4 Users Guide, 1990.) The superclass, Behavior, defines a factory method, parserClass, which Smalltalk-80 uses. This allows a class to use a customized parser for its source code. When an object requests a reference to a remote object, IONA Technologies uses this pattern in its Orbix ORB system to generate an appropriate type of proxy. (IONA Technologies, Ltd., Dublin, Ireland. Programmers Guide for Orbix, Version 1.2, 1994.)
Abstract Factory, Template Method, and Prototype patterns
Abstract Factory pattern, Factory Method pattern, Prototype pattern, Template Method pattern, creational patterns, Gamma patterns, Virtual Constructor pattern, object creation, system parameterization, parallel class hierarchies, object (defer creation)
any system requiring abstraction for object creation
do not know before hand all the classes that must be createdneed to defer object creation to classes with context, leaf classesneed to simulate virtual object construction
connects parallel class hierarchiesprovides hooks for subclass creation and extension
Test driver Test.javaProduct class Product.javaCreator class Creator.javaConcrete Product class ConcreteProduct.javaConcrete Creator class ConcreteCreator.javaTest driver testfactorymethod.cppSimple implementation of the pattern. factorymethod.h