Straight up: Design patterns are typical solutions to commonly occurring problems in software. Think of it as different songs that sound exactly the same — Flowers by Miley Cyrus & When I was your man by Bruno Mars or good 4 you by Olivia Rodrigo and misery business by Paramore. These songs have very similar melodies (design patterns) but are completely different songs (solutions to a particular problem).
What it’s not: Design Patterns are not solutions to every single problem you encounter as a developer. They are only used for specific, commonly re-ocurring problems.
Why should I learn this: To put it quite simply: it saves time, it’s readable, and it’s maintainable. These patterns are tried and tested solutions to common problems — which means that you won’t have to throw your computer out the window when trying to solve these problems and it allows you to write less code (which makes it easier for other devs to read and understand what is going on)
Here is why you shouldn’t learn this: When used incorrectly, design patterns can litter your code base with useless classes and pointless abstraction.
One of the biggest criticisms of design patterns is this:
“If all you have is a hammer, everything looks like a nail.”
Having learned about patterns, some software developers try to apply the patterns everywhere, even in situations where simpler code would work just fine.
There are 3 main groups of design patterns:
In this series, we are going to explore a couple of design patterns from each of these categories and discuss when to use them and when _not _to use them