This article is part of a series on introducing Design Patterns. In this article we introduce what Design Patterns are and why to use them. In other articles we will introduce specific Design Patterns, including when and how to use them.
Reinventing the wheel is a complete waste of time, so why do we do it so often during development?
Imagine, for a moment, that you were setting out to build a house. Nothing too fancy, just a little square building. Now imagine that you approached the problem as if you were the first person to ever try to build a building. That is, the structures and standards that go into a house — walls, ceilings, doors, windows, etc. — aren’t available to you; you have to invent these.
Hmm. What seemed not too bad a moment ago suddenly seems way more overwhelming.
As a developer, it’s tempting to approach each problem as if you’re the first person to come across it. The good news is that you aren’t.
In fact, most challenges during development are really quite common, and there are a number of tried-and-true approaches to solving these challenges.
They’re so common that they’re not specific to any one language and there’s a name for these: Design Patterns.
Patterns, not Packages
These days, virtually nothing is built from scratch. Almost every project uses a framework (WordPress, Laravel, CraftCMS, and on). Furthermore, developers use things like Tailwind CSS, React, Vue, and other packages to speed things up. These are ready-made solutions that you drop in and adjust for your uses.
Design Patterns have no visual component whatsoever. They are not packages, nor a framework. They’re much more conceptual, like building a wall. A wall is typically studs, drywall, and mud, but they don’t actually have to be. A wall can be any number of materials. You can’t just run to the store and buy a wall, you have to build one. But you don’t have to invent it. There are standards and ideas behind building walls that take into consideration height, whether it curves, if there’s a window, and many other scenarios. Others have already thought through this and put together specifications on how to build the wall.
You can’t just copy and paste a Design Pattern into your code and tweak it. You have to build it yourself, but what you build is guided by the pattern’s specifications.
Patterns for Object-Oriented Programming
There are groups of Design Patterns. Many can be used in a number of languages, but most are tied to a form of programming. Most of the patterns we will introduce in following articles are used in Object-Oriented Programming (OOP). There are patterns for other types, but we’ll stick mostly to OOP.
OOP is a great form of programming and a tried-and-true method of structuring one’s code. Most programming languages these days support OOP. A limit of OOP (and one that developers quickly realize when starting) is that while it tells you how to structure your code, it doesn’t actually tell you how to solve specific problems.
Why you should learn Design Patterns
It’s already been said that Design Patterns are a way of solving common challenges, but they’re more than just a solution. Having standard patterns within our code helps to improve its readability and scalability.
At Impress.org we have teams of developers working together to build our products. No one person can be depended upon to remember how our products are built. Design Patterns allow for us to look at one another’s work, understand how it’s built, and know how to extend it.
Furthermore, our products are used by tens of thousands of people, so it’s important that what we make them well-built to scale properly. The right pattern can make a big difference and protect us from backing ourselves into a corner.
Lastly, design patterns are a great way to grow as a developer. Many of the patterns are very clever and take a moment to understand. They’ll force you to think in ways you haven’t before, and that’s a good thing!
We never improve if we only expose ourselves to a single line of thinking, including our own or our teams’.
Next Steps & Upcoming Patterns
Over the following months we’re going to be sharing a series of articles that introduces specific Design Patterns. These are real patterns that we use within our work and find useful. We’ve not invented any of these (that’s the point!), but are happy to share to help others grow. Afterall, we’re all growing and improving every day.
We will cover three basic categories of Design Patterns:
- Creational— Methods for handling logic around object creation.
- Structural — Solutions which structure multiple objects together to solve a complex challenge.
- Behavioral — How a single object behaves such as an algorithm, complex value, or queue.
As a next step, we suggest jumping right in and searching for Design Patterns in the language you’re using. The sooner you start getting exposed to it, the better!