Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides
"Provide an interface for creating families of related or dependent objects without specifying their concrete classes." (Gamma, E., R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley, 1995)
A user interface toolkit that supports multiple look-and-feel standards, such as Motif and Presentation Manager. Different look-and-feels define different appearances and behavior for user interface "widgets" like scroll bars, windows, and buttons. To be portable across look-and-feel standards, an application should not hard-code its widgets for a particular look and feel. Instantiating look-and-feel specific classes of widgets throughout the application makes it hard to change the look and feel later. This problem can be solved by defining an abstract WidgetFactory (AbstractFactory in the thumbnail) class that declares an interface for creating each basic kind of widget. Theres also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. WidgetFactorys interface has an operation that returns a new widget object for each abstract widget class. Clients call these operations to obtain widget instances, but clients stay independent of the prevailing look and feel. There is a concrete subclass of WidgetFactory for each look-and-feel standard. Each subclass implements the operations to create the appropriate widget for the look and feel. For example, the CreateScrollBar operation on the MotifWidgetFactory (ConcreteFactory in the thumbnail) instantiates and returns a Motif scroll bar, while the corresponding operation on the PMWidgetFactory (ConcreteFactory in the thumbnail) returns a scroll bar for Presentation Manager. Clients create widgets solely through the WidgetFactory interface and have no knowledge of the classes that implement widgets for a particular look and feel. Clients only have to commit to an interface defined by an abstract class, not a particular concrete class. A WidgetFactory also enforces dependencies between the concrete widget classes. A MotifScrollBar (ConcreteProduct in the thumbnail) should be used with a Motif button and a Motif text editor, and that constraint is enforced automatically as a consequence of using a MotifWidgetFactory.
This pattern has been used on the following systems: InterViews (Linton, M.A., Encapsulating a C++ library. In Proceedings of the 1992 USENIX C++ Conference, pages 57-66, Portland, OR, August 1992. ACM Press.) 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, pages 46-57, San Diego, CA, September 1988. ACM Press.)
Factory Method, Prototype, and Singleton patterns
Abstract Factory pattern, Factory Method pattern, Prototype pattern, Singleton pattern, creational patterns, Gamma patterns, Kit pattern, families of objects, product construction, object creation, system parameterization
any system requiring abstraction for object creation
need a family of related product objects to be used together and you need enforcement of this constraintneed a system to support multiple families of classesneed interface to create objects without knowing their typesneed to provide a class library and want to reveal just the interfaces, not the implementations
isolates concrete classesmakes exchanging product families easypromotes consistency among products
supporting new kinds of products is difficult
Test driver Test.javaSimple implementation of the pattern - ProductB2 class. ProductB2.javaSimple implementation of the pattern - ProductB1 class. ProductB1.javaSimple implementation of the pattern - ProductA2 class. ProductA2.javaSimple implementation of the pattern - ProductA1 class. ProductA1.javaSimple implementation of the pattern - ConcreteFactory2 class. ConcreteFactory2.javaSimple implementation of the pattern - ConcreteFactory1 class. ConcreteFactory1.javaSimple implementation of the pattern - AbstractProductB class. AbstractProductB.javaSimple implementation of the pattern - AbstractProductA class. AbstractProductA.javaSimple implementation of the pattern - AbstractFactory class. AbstractFactory.javaTest driver testfactory.cppSimple implementation of the pattern. abstractfactory.h