• 4 hours
  • Easy

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 2/18/22

Program Efficiently With Design Patterns

What if you are driving a car and one of the tires goes flat? 🚗 This is a problem that happens often enough that people have come up with a solution. (Well, other than calling a tow service.) The answer is that the car has an extra tire, just in case. It's called a spare tire.

This is an example of a pattern. A problem that occurs so often, it is given a name and a known solution. I can say spare tire, and immediately you know what I mean. Now, each car has a different implementation of the idea. Some spare tires are small, and others are full-sized. Some are easy to find in the trunk; others are not. But the big picture is, you know what I mean when I refer to the spare.

What Is a Design Pattern?

A design pattern is a proven, reusable solution to a commonly occurring problem. It describes the static or dynamic nature of classes and objects that implement the solution. You are free to tailor the solution to fit your particular situation, like the spare tire size in my example.

Patterns are usually described with four attributes:

  • Name

  • Problem

  • Solution

  • Consequences

The name allows you to describe the situation at a high level. It gives a universal language.

The problem indicates the situation where the pattern can be applied. This is the toughest part - being able to recognize the problem at hand and picking the correct pattern. Let's look at several patterns in depth. Part of that look is recognizing the problem.

For example, in our card game, we need to generate different decks, with different numbers of cards in them. A pattern exists that lets us do this.

The solution provides the arrangement of classes and objects that make the pattern work. You may make changes to suit your application but still need to keep to the spirit of the pattern. For example, we will use a pattern for our deck generation. The pattern says nothing about generating playing card decks; but rather, a general-purpose way of generating objects of any kind. So we tailor the pattern to do just that.

The consequences are what happens when you apply the pattern. Every pattern has at least one positive consequence. It solves the problem. But sometimes there may be negative consequences. Going back to the spare tire example, the size of the tire impacts your ability to carry other things in the trunk.

Where did patterns come from?

Back in 1994, the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) released the book Design Patterns: Elements of Reusable Object-Oriented Software. These four authors looked at over 300 projects that other developers were working on. They recognized that many of the same problems kept appearing.

They also noticed that these various projects solved the problems in roughly the same way. Their book discusses these problems and solutions, giving them the name patterns. They categorized the patterns into three sections:

  1. Creational patterns - patterns concerned with creating objects.

  2. Structural patterns - aligning classes and objects.

  3. Behavioral patterns - interactions between objects. 

In this part, we will look at samples of all three types.

Why Use a Design Pattern?

You run into problems with organizing software all the time. You can always “hack” out a solution, but it leads to long-term problems that are hard to understand and maintain. You want to avoid bad coding practices. Recognizing patterns is one way to keep code clean.

The biggest advantage of using a design pattern is that you know that the solution works. But there are other advantages as well.

One is the understandability of the code. Patterns have been previously well-documented. You don’t need to recapture all the diagrams and descriptions. You already know what to expect in terms of the implementation. It’s just a matter of creating the specifics in your code.

Another is that the level of communication between developers is elevated. You don’t have to go through a full explanation; you can jump to the pattern name. For example, I don’t have to say, “Do you have one of those extra tires in the trunk, in case you get a flat?” I can ask if you have a spare, and you know what that means.

Let's Recap! 

  • Patterns are proven, reusable solutions to commonly occurring problems.

  • Patterns are described with four items:

    • Name

    • Problem

    • Solution

    • Consequences

  • Using patterns lead to better understandability and maintainability.

  • There are three types of patterns:

    • Creational

    • Structural 

    • Behavioral 

In the next chapter, we will look at the first set of patterns. Those associated with creating objects, or the creational patterns.

Example of certificate of achievement
Example of certificate of achievement