Links

The Abstract Factory design motif

The informal description: Excerpts from [Gamma et al. 1995] (adapted for this purpose):

Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Structure: Original OMT diagram converted to UML (Why and How?):

Participants:

• AbstractFactory (WidgetFactory): declares an interface for operations that create abstract product objects.
• ConcreteFactory (MotifWidgetFactory, PMWidgetFactory): implements the operations to create concrete product objects.
• AbstractProduct (Window, ScrollBar): declares an interface for a type of product object.
• ConcreteProduct (MotifWindow, MotifScrollBar): defines a product object to be created by the corresponding concrete factory; implements the AbstractProduct interface.

Collaborations: AbstractFactory defers creation of product objects to its ConcreteFactory subclass.

Formal specification

See also:

• Legend: Key to LePUS3 and Class-Z Symbols
• Reference Manual for LePUS3 & Class-Z
• Abstract Factory in XML
• Modelling Design Patterns: Frequently-Asked Questions

Abstract Factory in LePUS3 (legend)
Abstract Factory in Class-Z (legend)

Sample Implementations

Informal description: Widget Factories

The example of cross-platform factories of graphical user interface widgets is described in [Gamma et. al 1995] as follows:

Consider 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 behaviors 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.

We can solve this problem by defining an abstract WidgetFactory class that declares an interface for creating each basic kind of widget. There's also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. WidgetFactory's 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 aren't aware of the concrete classes they're using. Thus clients stay independent of the prevailing look and feel.

Formal specification: Widget Factory

Specified in LePUS3 and Class-Z (see legend)

Widget factory example modelled in LePUS3 using 1 and 2-dimensional hierarchy constants (legend)
Widget factory example modelled in LePUS3 using 1-dimensional hierarchy constants (legend)
Widget factory example modelled in LePUS3 using 0-dimensional class and signature constants (legend)