This article represents an introduction to the world of design patterns. 

In my collection of design patterns articles, I try to introduce them from a different, more practical angle, than other articles I found online.

Most articles try to explain design patterns in an abstract way, and give approximate examples of them hoping they can be understood. I, on the other side, find it difficult to understand them that way. I prefer to have a real code example of each design pattern. So, let’s get started ! 

What is a pattern ? 

Referring to google translate here is what a pattern is: 

  1. A regular and intelligible form or sequence discernible in the way in which something happens or is done. 
  2. A repeated decorative design
  3. Simply, a pattern represents a repeated collection of actions that happen often in the same way and succession. 

Going to work, school, or university represents a pattern. Waking up every morning, dressing up, using public transport, and getting to work, then leaving it, etc. 

What ARE a design patterns ? 

I don’t want to repeat what you can easy find online. So here are a couple of definitions of design patterns from a few references.  

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design 


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

The book of GOF

Elements of Design Patterns 

In general, a pattern has four essential elements 

  • The name of the pattern. The name represents a handle that we can use to describe a design problem, its solution, and consequences in simple words.
  • The problem. Describes when to apply the pattern, the problem and it’s context. 
  • The solution of the problem. 
  • The consequences. They are the results and trade-offs of applying the pattern.  

Types of Software Design Patterns  

We can put design patterns into 3 groups considering the kind of problem they solve. 

  • Creational, as the name reveals, the problem they solve is creating something. To be more concrete they create objects. 
  • Structural, these patterns describe how we can combine objects and classes to form structures. 
  • Behavioral patterns, they are patterns that focus on the interaction between cooperating objects.

 Keep in mind 

When it comes to using patterns there are several things one should keep in mind.

  • They are rarely used in real life situations. During my development career, which I don’t consider to be a long one (around 5 years),  I don’t remember using more than 10% of the patterns and I mostly needed them during job interviews. This doesn’t mean they are not important or are inappropriate but in fact very few developers understand and use them correctly. And if they do – they don`t really do it on purpose.
  • Design patterns change over time. Programming languages evolve, new ones come. Many patterns were designed to solve some problem that the language itself produced. We will see examples of these when we put some design patterns in the light of Java 8. 
  • Don’t solve problems that don’t exists. Consider if the problem really exists and if that solution is actually needed. Using design patterns in every piece of code is not a good practice, neither is their overuse.

Next -> Creational Design Patterns














Comments (1)

  1. Pingback: Design Patterns Examples in Java - Factory Pattern - The code rider

Leave a comment

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