Skip to content
On this page

Design Patterns

We will investigate a handful of design patterns (in the context of OOAD) in this course.

Definition

A design pattern is a proven, reusable solution to a commonly occurring problem.

Detour: Where is your spare?!

What?! ... Well, that question would have made sense if we were going to take a road trip in a car. In that context, you would know what I am asking about: a spare is an extra tire you carry in your car in case you are driving and one of the tires goes flat. Let's take a moment and reflect on this:

  • Problem: when driving a car, a tire might go flat.
  • Solution: change the tire (requires to have an extra tire).
  • The problem happens often enough that manufacturers, by design, equip your car with an extra tire, just in case.
  • The extra tire is called a spare.

This is an example of a design pattern! A problem that occurs so often that it is given a name and a known solution. So when I say "where is your spare?" (before a road trip) you immediately know what I mean and why I ask for it.

A bit of history: Gang of Four!

Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (collectively known as the Gang of Four or GoF) wrote the book Design Patterns: Elements of Reusable Object-Oriented Software in 1994. These authors looked at over 300 projects that other software developers were working on (at the time):

  • They recognized that many of the same problems kept appearing.
  • They also noticed that solutions to the problems were roughly the same.
  • Their book discusses these problems and solutions, identifying each as a pattern and giving it a name.

GoF categorized the patterns into three categories:

  • Creational patterns - writing classes and creating objects.
  • Structural patterns - aligning classes and objects.
  • Behavioral patterns - interactions between objects.

We will look at samples of all three types.

Why should you learn about design patterns?

First and foremost to write good software: recognizing patterns can help you write code that is easy to maintain in the long-term; it helps you avoid writing hacky code. By "hacky code" I mean a software solution that accomplishes some goal by compromising on design principles that (good) programmers would much rather not compromise on.

INFO

The hardest part of applying patterns is being able to recognize them! That is, to identify the problem at hand as the underlying problem of a pattern.

Another reason is to be able to communicate with other software developers. It is typical during design sessions and code reviews, developers communicate by using pattern names without giving a full explanation as to what the problem and its solution are.

Released under the MIT License.