Home » Design Patterns » Design Patterns – introduction

Design Patterns – introduction

Design patterns which I would like to present in this post are well described in the book Design Patterns. Elements of Reusable Object-Oriented Software  written by The Gang of Four (Gramma, Helm, Johnson, Vlissides). In my opinion this book is must read for every developer, regardless what programming language you are using. Besides the fact that this book was written more than 20 years ago, it still contains a lot of useful details for developers of all levels. I often revisit this book to keep in touch with design patterns that are detailed within.

What is it?

To describe what design patterns are I will show a quote from the previously mentioned book:

“[Design patterns] are descriptions of communicating objects and classes that are customized to solve a general design problem in particular context”.

What this quote points at is, if we have a problem and someone else in the past had the same problem, we might use design patterns to solve it, right? Both yes and no. Let me explain why it’s not that easy to use design patterns in the code, however, before that I’ll list all of them.

In this book, you’ll find three design patterns’ groups.


Creational design patterns add abstraction around how objects are instantiated. Believe me, these design patterns may help you when your system grows. This group consist of:

  • Abstract Factory,
  • Builder,
  • Factory Method,
  • Prototype,
  • Singleton


Structural design patterns are concerned with the way how objects and classes are composed together to form larger structures. This group consist of:

  • Adapter,
  • Bridge,
  • Composite,
  • Decorator,
  • Façade,
  • Flyweight,
  • Proxy


Behavioural design patterns are concerned about the way how algorithms and responsibilities are stored between objects. This group consist of:

  • Chain of Responsibility,
  • Command,
  • Interpreter,
  • Iterator,
  • Mediator,
  • Memento,
  • Observer,
  • State,
  • Strategy,
  • Template Method,
  • Visitor
In the coming weeks, I will write articles about each design pattern I’m using every day and I’m going to present my implementation in the code. I hope someone will find it useful.

Why implementation is not that easy?

First, a developer who is using design patterns needs to understand them and remember that these exist! I’ve read this book, cover to cover, twice and, while writing this post, I can’t remember when I was using i.e. Visitor or Memento. I know, it’s a shame, however in my job I never found a way how to implement them or I just forgot that they exist.

Second, let’s assume I’m working in a team of four developers (including me) where two are juniors who just started they journey in software engineering. Using every single design pattern in this team would be a disaster, because fully understanding design patterns requires a lot of time and practice. Moreover, the level of code understanding might be different between each person in the team (regardless of experience).

Third, in my opinion using design patterns in simple solutions is just over-engineering. If it’s something simple and can be done quickly, just don’t bother yourself. Write the code and move on.

Fourth, on the other hand, you wouldn’t like to see the code where you’ll find every single design pattern. I’ve seen a lot of different types of code in my entire life, however, the hardest to maintain is the code where simple algorithms are described as difficult to understand implementations of design patterns.

Published by

Mateusz Pustelak

Software Developer with several years of commercial experience, TDD practitioner, DDD/CQRS fan. Currently working for Universal Music Group in London.

Leave a Reply

Your email address will not be published. Required fields are marked *