Card 02/ 08
Abstract Factory Pattern Structure: The Class Diagram
An AbstractFactory with one create method per product, and one ConcreteFactory per family.
Abstract Factory has five participants: the abstract factory, a concrete factory per family, an abstract product per kind of object, a concrete product per kind and family, and the client that uses them. This card reads each role off the Gang of Four's class diagram, and shows why the diagram grows in two directions at once.
| Participant | Role |
|---|---|
| AbstractFactory | Declares one creation method for each kind of product, each returning an abstract product. |
| ConcreteFactory | Implements every creation method for one family. ConcreteFactory1 returns only family 1 products. |
| AbstractProduct | The interface for one kind of product, such as storage or a queue. |
| ConcreteProduct | One kind of product from one family, such as ProductA1. |
| Client | Holds an AbstractFactory and uses only the abstract product interfaces, so it never names a concrete class. |
Read the concrete products as a grid. The letter is the kind of product and the number is the family, so ProductB2 is the second kind from the second family. Each concrete factory owns one row of that grid, the number, and each abstract product owns one column, the letter.
That grid is why the diagram grows in two directions. A new family adds a row: one concrete factory and one product for each kind. A new kind of product adds a column: one abstract product, one concrete product for each family, and a new method on the abstract factory and on every concrete factory. The second direction costs more, because it edits classes that already work.
Look closely at a single concrete factory and you will see a set of factory methods, one per product. The difference from Factory Method is where the choice lives: there, a subclass overrides one method of a class that also does other work; here, an object exists only to create, and the client is handed it.
← → move through sections and cards