I believe the key to understand anything is to ask questions. It does not matter if the question was right or wrong, because often the question is judged based on others perspective.

He who asks a question remains a fool for five minutes. He who does not ask remains a fool forever.

So let's try to understand Design Patterns with a few basic questions.

What ?

Engineer's job is to design and build things. Irrespective of the field, we face problems which seem to repeat themselves.

When these problems show up again and again, then instead of reinventing the wheel and trying to solve the problem from scratch, a group of engineers got together and addressed these problems.

They came up with a generalized solution which can act as a blueprint. These blueprints are called Design Patterns.

Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

It's easy to confuse between algorithms and design patterns. Algorithms give us a very specific number of steps, that we need to repeat exactly as stated. For example consider a cooking recipe, we are given the exact ingredients and we need to follow every step as it is.

Design patterns on other hand give us a birds eye view of the end solution and the features, but does not inform us about the exact implementation. The implementation is left to us. For example consider a blueprint of your house, it tells you how the end result will look like and what all features your house will have but it does not give you specific details on how to actually build it.

Why ?

You might be able to manage as a developer for many years without learning these design patterns , but I am positive that you must have unknowingly used it, or as I like to call it, reinventing the wheel for a commonly seen problem.

Design patterns are tried and tested solutions to common problems we see in software development. Now, there have been counter arguments that learning design patterns is a waste of time because most modern languages have built-in capabilities which lets us use these design patterns. They expose only necessary things and abstract away all the juicy implementation details.

I beg to differ, because even-though I don't like to reinvent the wheel I still want to know how it was invented. So it's a no brainer to learn them, and add them to your arsenal.

Even if you don't use them, learning them will enhance your object oriented programming skills for sure.

A word of caution !!

A design pattern can act like a Katana sword, which will help you cut down anything with ease, but never use a sword to chop vegetables. Once you learn these design patterns, you should always carefully analyze which design pattern to use given the context of your project. It might happen that you don't even need it. Using these design patterns when not necessary can add on to more technical debt.

So use a knife to chop vegetables and leave that shining katana sword passed down through generations alone, even if it's very tempting and above all would look cool.

How Many ?

There are lots of design patterns documented over the years. Design patterns vary in complexity, behavior and scale of applicability.

They can be categorized into Creational Pattern, Structural Pattern and Behavioral Pattern. The differences between these categories will be better understood when we dive into individual pattern.

I hope I was able to shed some light on design patterns. I know they might sound intimidating and complex to understand but hey, these design patterns were designed by engineers and fellow humans, so how difficult can they be.