Introduction to Design Patterns

I hate the feeling when I don't know something.

This is where impostor syndrome hits.

I had this feeling when my teammate said, "Oh, just use X pattern" and I had no idea what that was.

This is why I've studied and scoured the internet for all sorts of resources on design patterns.

I'm gonna jumble them all up into this series on design patterns.

This is the first post of the series, where we will go over:

• What are design patterns?
• History of design patterns
• Why should you learn them?
• Different types of design patterns

Design Patterns

If you google design patterns, you would get something like this:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code.

Honestly this sounds way too complicated.

Basically, a design pattern is a solution to a common problem in software design. You can think of them as blue-prints that you can customize to solve a recurring problem in your code.

Patterns are not snippets of code, that you can simply copy. Patterns give you a general solution, you can follow and alter the solution to fit your application specific needs.

Patterns are often confused with algorithms, they both indeed offer a solution to common problems. Algorithms give a step-by-step guide to the solution while a pattern gives more of a high-level concept of the solution.

History of patterns

Patterns are not only used in software, they are also used in other fields of engineering. A pattern is simple a common solution to a recurring problem, this description can be applied to many different fields.

The concept of a pattern first came in civil engineering by an engineer named Christopher Alexander. While working on designing buildings and towns, he saw that there came many recurring problems and general solutions to solve them. He documented his experience in his book A Pattern Language: Towns, Buildings, Construction.

The same idea was picked up by software developers notably:

• Erich Gamma
• John Vlissides
• Ralph Johnson
• Richard Helm

In 1994 they wrote the first book on software design patterns named Design Patterns: Elements of Reusable Object-Oriented Software. This book introduced 23 patterns solving various problems of object-oriented design. Due to its long name, people started calling it "the book by the gang of four", which was soon shortened to "the GoF book".

Why should I learn patterns?

I personally know many developers who don't know any patterns but manage just "fine". A lot of developers are like that. They even might be implementing some patterns without even knowing it. So what's the point of learning these so called "patterns"?

• Design patterns is a toolkit of solutions to common problems. Even if you won't ever encounter such problems, it's still beneficial to know how to solve them using object-oriented design principles.
• It provides a common language between developers. You can simply say to your colleague, "Oh, just use a singleton for that", and everyone will understand you. There's no need to explain what a singleton if you already know the pattern.

Type of Design Patterns

Patterns can be categorized by their intent, or purpose. The three main groups of patterns are:

• Creational patterns: helps us better create/instantiate objects, making them more flexible and reduces code duplication.
• Structural patterns: helps us combine objects into larger entities while maintaining flexibility and efficiency.
• Behavioral patterns: helps us with communication between objects, makes sure to reduce side effects.

Conclusion

I hope you were convinced by the end of this to study design patterns, or to at least think about them. In the upcoming weeks I will dedicate a post to a specific pattern, so stay tuned for that.

As always if you have any questions, feel free to leave them down in the comments and I will get back to you.