markdown guide
 

The short version of it is that design patterns are way the reuse "ways of designing software" the same way a library allows you to reuse code.

Say you have a recipe to pan fry eggs. You also have a recipe to pan fry a steak. You can think of "pan frying" as a design pattern for cooking. If I ask you to pan fry a fish, even if you've never done it you can make a pretty reasonable guess how to do it. The same way, when you end up using the same sort of thinking to solve similar, but unrelated problems, you're using design patters.

There are some very common and well known patterns. The GoF documented some, and they've allowed us to put a name to ways of thinking about design. The common language allows developers to communicate ideas faster and more easily.

The opposite of a "design pattern" is an anti-pattern. They are common ways to shoot yourself in the foot with your code. You build your professional toolbox by knowing an using design patters, as well as by knowing and avoiding anti-patterns.

While some design patterns are seen in any programming language, some patterns are specific to one or a handful of similar languages.

 

That frying pan analogy really put it together for me. Thank you.

 

Design patterns are like a variable in math. It's just a name used to represent some common implementation.

I actually strongly dislike it when people use a lot of pattern names when they describe a system. Even if I know the patterns, there can be some variation in implementation. So it's like they just gave me a math problem to work out.

 
 

Guidelines to the most common problems.

They exists for OOP, FP, concurrency and so on.

Classic DEV Post from Mar 21

Use Your Voice Effectively for Impactful Presentations

Learn how to use your voice to be an effective storyteller in presentations.

Tiffany White profile image
Open source enthusiast, autodidact, JavaScript hacker, React fangirl and herder of cats 🐈.