Design Patterns: Abstract FactoryBlog

Introduction

This post gives a brief overview about the Abstract Factory Pattern. The post is part of a series about software design patterns and their UML representations with the help of PlantUML.

The article aims at providing a very short description of the general idea of the pattern in the first part. This also involves a descriptive UML diagram. Then, the second part provides the PlantUML code for the diagram so that these posts can also be used as a source of design patterns in PlantUML syntax.

What is the Abstract Factory Pattern?

The Abstract Factory Pattern solves problems like:

• How can an application be independent of how its objects are created?
• How can a class be independent of how the objects it requires are created?
• How can families of related or dependent objects be created?

Creating objects directly within the class that requires the objects is inflexible because it commits the class to particular objects and makes it impossible to change the instantiation later independently from (without having to change) the class. It stops the class from being reusable if other objects are required, and it makes the class hard to test because real objects can’t be replaced with mock objects.

The Abstract Factory design pattern describes how to solve such problems:

• Encapsulate object creation in a separate (factory) object. That is, define an interface (AbstractFactory) for creating objects, and implement the interface.
• A class delegates object creation to a factory object instead of creating objects directly. UML Diagram

The following diagram shows the Factory Method Pattern in UML notation. It is based on the corresponding chapter in the book “Head First Design Patterns“:

You can click on the diagram to open it online in Pladitor.

Diagram Sources

Here are the diagram sources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

@startuml

hide empty fields
hide empty methods
skinparam Nodesep 50
skinparam Ranksep 40

class Client
interface AbstractFactory
interface AbstractProductA
class ProductA2
class ProductA1
class ConcreteFactory1
class ConcreteFactory2
interface AbstractProductB
class ProductB1
class ProductB2

Client --> AbstractFactory
Client --> AbstractProductA
Client --> AbstractProductB
AbstractFactory <|.. ConcreteFactory1
AbstractFactory <|.. ConcreteFactory2
AbstractProductA <|.. ProductA1
AbstractProductA <|.. ProductA2
AbstractProductB <|.. ProductB1
AbstractProductB <|.. ProductB2
ProductA1 <-down- ConcreteFactory1
ProductB1 <-down- ConcreteFactory1
ProductA2 <–down- ConcreteFactory2
ProductB2 <–down- ConcreteFactory2

note right of Client
The Client is written against the
abstract factory and then composed at
runtime with an actual factory.
end note

note bottom of AbstractFactory
The AbstractFactory defines
the interface that all Concrete
factories must implement which
consists of a set of methods
for producing products.
end note

note "The concrete factories implement the\ndifferent product families. To create a\nproduct the client uses one of these factories,\nso it never has to instantiate a product object." as n1
ConcreteFactory1 .. n1
ConcreteFactory2 .. n1

note left of AbstractProductB
This is the product
family. Each concrete
factory can produce an
entire set of products.
end note
@enduml

Open this diagram online with Pladitor.