Having a common vocabulary for describing design patterns is useful, however it can be difficult to fully grasp the concepts at a high level with a textual description alone; for many people, being able to visualize a design pattern brings the concepts into grasp. For this reason, many design patterns are modeled as Unified Modeling Language (UML) class diagrams.

Assumptions:

Basic programming knowledge
Familiarity with Object-Oriented Programming

What is UML?

The Unified Modeling Language (UML) is a formal language designed for representing systems and flows within a software application. Unlike a programming language, UML is not something which is programmed; UML consists of diagrams to help visualize a software's design.

There are many kinds of UML diagrams, however for the sake of design patterns, the class diagram suffices.

UML Class Diagram

UML class diagrams visualize how various classes interact with each other. A typical "class" might look like the following:

</div>

The first box is a basic definition of a class in UML, containing only one "compartment" that gives it a name. Classes can have up to three compartments, like the second box, which describe the name, member variables, and methods (functions) of the class.

The symbols on the left of the second diagram have a meaning as well, defining whether a variable or method is public +, private -, protected #, or a package ~.

Types of Associations

Now that we know how to represent classes on their own, we need to define different ways that classes relate to each other. These relationships are represented with various types of lines called Associations.

Association

An association defines a basic relationship between two classes; when an association is drawn between two classes, it usually means that they are in some way related or contain a reference to one another.

Aggregation

When conceptualizing aggregation, think "A has b". For example, a classroom has students. The important distinction of aggregation, though, is that the students are able to exist without the classroom.

Further, aggregation must be a binary association; it can only involve at most two classes.

Composition

Composition can be described as one class being part of another class; "A is part of B". Unlike aggregation, A exists only if B exists.

For example, a classroom has students (aggregation), but a classroom is composed of four walls and a door; without these parts, the classroom (by this definition) would not exist. If you destroyed the classroom, you would have to destroy the walls and door. However, if you destroyed the classroom, the students would still exist.

> Composition implies ownership of the objects within it.

Generalization/Specialization

When a class can be abstracted to a general concept that it shares in common with other classes, then a class can be created which is a generalization of the two; the common classes inherit from this generalization and become specializations.

> As a general rule of thumb, you should favor composition over inheritance!

Realization

A realization is similar to a generalization, except that instead of inheriting from the parent class, it implements the parent, usually as an interface or abstract-class. Realization can be expressed as either a dotted line and arrow, or a lollipop notation.

Dependency

A dependency is like an association, however it usually means there is a weaker relationship between the two classes, like if class A requires a reference to class B as a parameter to a function.

Multiplicity

Sometimes you might see notation like 1..* next to an association between two classes. This defines the number of instances of a particular class expected by the second class. For example, 1..* means one or more instances are needed. here are some common multiplicities to give an idea of how they are formatted:

Multiplicity	Definition
0..1	zero or one
1 or 1..1	only one
* or 0..*	zero or more
1..*	one or more

Practical Modeling

In the real world, the complexity of UML diagrams varies from developer to developer. Some might prefer thorough documentation in their class diagrams, some might just use boxes and lines, and some might not use them at all!

Despite the differences in approach, it is important to understand the basics of class diagrams for design patterns, so that whether you prefer detailed diagrams, simple diagrams, or none at all, you can still understand the ideas being communicated.

Further Resources

<a href="https://www.uml.org/index.htm" target="_blank" style="color:#fff;border-radius:3px;background-color:#888;padding:1px 5px">Official UML Website</a>: For a detailed and up to date documentation on all of the Unified Modeling Language.
<a href="https://www.draw.io" target="_blank" style="color:#fff;border-radius:3px;background-color:#888;padding:1px 5px">Draw.io</a>: A free, open-source tool for designing diagrams with built-in support for UML diagrams to make your own!