Design Patterns

Abstract Factory



Design Pattern Type: Creational

GoF Statement of Intent:


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



Encapsulates a group of individual factories that have a common theme. The client object creates a concrete (subclass) implementation of the abstract factory then uses the generic interface defined by the parent Abstract Factory class to use the factory to create objects. The client does not know or care which of the concrete objects it gets from the factory since it only uses the generic interfaces to the objects. Thus the details of the implementation of an object is separated from their actual usage, i.e. you may call a generic "execute" function in the object without caring what the object actually does. A simple example is an abstract factory called DocumentCreator. It has interfaces to create a number of products such as createLetter() and createResume(). The DocumentCreator factory may have subclasses such as FancyDocumentCreator or ModernDocumentCreator. When createLetter() is called on the FancyDocumentCreator it returns an instance of FancyLetter. When createResume() is called on ModernDocumentCreator it returns an instance of ModernResume.

UML Diagram:

Discussion and In-class Example:

The Abstract Factory Design Pattern is similar to the Factory Method but in this pattern we completely remove from the subclasses the responsibility for creating the appropriate "concrete product" and encapsulate it in a concrete Factory class which is a subclass of an Abstract Factory parent class. In the Abstract Factory we continued with the the example of the PizzaShop from the Factory Method discussion.

We found that in addition to different style and types of pizzas the ingredients themselves had to vary by style. For example all the New York style pizzas used ThinCrustDough, while all the Chicago style pizzas used ThickCrustDough, and all the California style pizzas used VeryThinCrustDough. The same held true for the sauce, cheese, veggies, etc. resulting in the need for several "Families of Ingredients."



The solution to this problem lay in the Abstract Factory pattern. We modified the Pizza class so that it held a reference to a PizzaIngredientFactory (the Abstract Factory parent class). Now there was no need for any of the subclasses of Pizza. All the (changable) details of creating a pizza has now been encapsulated in a PizzaIngredientFactory. All of the Pizzas created by a NYStylePizzaShop create a NYPizzaIngredientFactory, all of the pizzas created by a ChicagoStylePizzaShop create a ChicagoPizzaIngredientFactory, and all of the pizzas created by a CaliforniaStylePizzaShop create a CaliforniaPizzaIngredientFactory.


The Abstract Factory Design Pattern is very powerful and is used a lot in simulations where objects in a simulation may change frequently. All the change is isolated in the Factory so that the actual simulation does not need to change.