DEV Community

Cover image for Introduction to Design Patterns
Tamerlan Gudabayev
Tamerlan Gudabayev

Posted on • Updated on

Introduction to Design Patterns

I hate the feeling when I don't know something.

This is where impostor syndrome hits.

I had this feeling when my teammate said, "Oh, just use X pattern" and I had no idea what that was.

This is why I've studied and scoured the internet for all sorts of resources on design patterns.

I'm gonna jumble them all up into this series on design patterns.

This is the first post of the series, where we will go over:

  • What are design patterns?
  • History of design patterns
  • Why should you learn them?
  • Different types of design patterns

Design Patterns

Alt Text

If you google design patterns, you would get something like this:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code.

Honestly this sounds way too complicated.

Basically, a design pattern is a solution to a common problem in software design. You can think of them as blue-prints that you can customize to solve a recurring problem in your code.

Patterns are not snippets of code, that you can simply copy. Patterns give you a general solution, you can follow and alter the solution to fit your application specific needs.

Patterns are often confused with algorithms, they both indeed offer a solution to common problems. Algorithms give a step-by-step guide to the solution while a pattern gives more of a high-level concept of the solution.

History of patterns

Patterns are not only used in software, they are also used in other fields of engineering. A pattern is simple a common solution to a recurring problem, this description can be applied to many different fields.

The concept of a pattern first came in civil engineering by an engineer named Christopher Alexander. While working on designing buildings and towns, he saw that there came many recurring problems and general solutions to solve them. He documented his experience in his book A Pattern Language: Towns, Buildings, Construction.

The same idea was picked up by software developers notably:

  • Erich Gamma
  • John Vlissides
  • Ralph Johnson
  • Richard Helm

In 1994 they wrote the first book on software design patterns named Design Patterns: Elements of Reusable Object-Oriented Software. This book introduced 23 patterns solving various problems of object-oriented design. Due to its long name, people started calling it "the book by the gang of four", which was soon shortened to "the GoF book".

Why should I learn patterns?

I personally know many developers who don't know any patterns but manage just "fine". A lot of developers are like that. They even might be implementing some patterns without even knowing it. So what's the point of learning these so called "patterns"?

  • Design patterns is a toolkit of solutions to common problems. Even if you won't ever encounter such problems, it's still beneficial to know how to solve them using object-oriented design principles.
  • It provides a common language between developers. You can simply say to your colleague, "Oh, just use a singleton for that", and everyone will understand you. There's no need to explain what a singleton if you already know the pattern.

Type of Design Patterns

Patterns can be categorized by their intent, or purpose. The three main groups of patterns are:

  • Creational patterns: helps us better create/instantiate objects, making them more flexible and reduces code duplication.
  • Structural patterns: helps us combine objects into larger entities while maintaining flexibility and efficiency.
  • Behavioral patterns: helps us with communication between objects, makes sure to reduce side effects.


I hope you were convinced by the end of this to study design patterns, or to at least think about them. In the upcoming weeks I will dedicate a post to a specific pattern, so stay tuned for that.

As always if you have any questions, feel free to leave them down in the comments and I will get back to you.

Top comments (8)

peerreynders profile image

The 4 Stages of Learning(/Adopting) Design Patterns

  1. Ignorance
  2. Awakening
  3. Overzealousness
  4. Mastery

Stage 3: Overzealousness is the dangerous one - implementing patterns everywhere even in "square peg in a round hole" situations.

It comes down to many people treating patterns as "cookbook recipes for solution implementations".

Design patterns principally serve as a vocabulary (or nomenclature) for more precise and effective communication. For example, when the term "Façade" is referenced (in conversation or in print) it should be clear to all parties involved what is being referenced without having to go into details - making communication more efficient.

hasnaindev profile image
Muhammad Hasnain

One of the best post I've seen on Clean, easy to understand. I saw the chart and realized that React follows the component based architectural style and this isn't its own invention. By any chance, do you read software engineering related books like the one you mentioned in the post?

tamerlang profile image
Tamerlan Gudabayev

Hi, yea I do read lots of books. You can check out my reading list, it consists of books that I'm reading in 2021.

hasnaindev profile image
Muhammad Hasnain

Damn, thanks for creating the list. Really appreciated! One question though: Paperback or e-books?

Thread Thread
tamerlang profile image
Tamerlan Gudabayev

I use a kindle, so ebook :D

bikashd4332 profile image
Bikash Das

This happened with me few times as well.

So here is this place,,
where I go and find the pattern when I don't seem to know much about it.

tamerlang profile image
Tamerlan Gudabayev

Yes, I seem to forgot to the put the "Further Readings section" but I would highly recommend Diving into Design Patterns and Head First Design Patterns.

ashishk1331 profile image
Ashish Khare😎

What a bouncer, swiftly crossed my head! An example first approach would have been appreciated. Rest....