Learning design patterns reminds me a lot of video games and the learning curve of how to build correctly in many of today’s games. Take, for example, Elden Ring, a recent game I’ve been playing, which is an open world dark souls game in which you can customize your character by equipping them with hundreds of weapons and armor and putting points into specific attributes of your character. This is a lot like the many design patterns that exist today. There can be patterns for different frameworks and languages, and each of those could have their own unique variations of how they implement that specific design pattern. Like in Elden Ring, you don’t want to walk around the world without the best build unless you enjoy looking at the death screen. And in programming, you should be recognizing these design patterns in order to more easily learn and program more structured code to prevent your code from becoming spaghetti.
In Elden Ring, knowing how different items, weapons, and stats play together helps players come up with new, stronger builds. In programming, learning these design patterns helps you take a step back and look at code at a higher level. Maybe instead of using a bunch of if/else statements, you would use a case/switch structure and then suddenly realize that writing individual functions for every condition and placing them in objects with the cases being keys would make it much easier, which is an example of the Strategy pattern. Or maybe you could be writing a for loop and then suddenly realize that it might be easier to write a function inside of a forEach, which is an example of the Visitor pattern. If you use ReactJS, you have most definitely used the Visitor/Builder pattern when separating components from pages. The different approaches and combinations to solving a problem are seemingly endless, but guides found online and written in books such as the “Gang of Four” help developers recognize and understand these patterns. Just like when playing Elden Ring, many players may not have any knowledge of different building paths until they read a guide.
In software engineering, oftentimes you need to remember that you are not just programming for the customer or even for yourself. You are programming for the next person, the person that will need to look at and maintain the code that you have written. If this code is not readable, then it can be hard to pinpoint where things are in the code. Ultimately, this means that bugs will be harder to find and that a fix that could have taken 1 or 2 hours becomes a mystery case of finding out where and what your code does. Design patterns are the “blueprints” to make sure your code is easier to read and navigate for other developers. Design patterns also help programmers communicate with one another and convey thoughts easily. Instead of trying to explain to someone how and why you have chosen a certain approach, you can say “I have built this with MVC in mind” and other programmers will understand your intentions and code.