The most common definition (or as far as I could see) of design patterns is that they are a general, reusable solution to a commonly occurring problem in software design, similar to a template that can be used in many different situations. The 3 main patterns are creational, structural, and behavioral patterns. Creational patterns help create objects, structural patterns help to represent collections of objects, and behavioral patterns help manage interactions between objects.
Initially learning about design patterns was a bit of a challenge for myself because I kept on interpreting them as “templates.” However, “templates” is too definitive for the idea of a design pattern. It seems very black and white with that analogy; however, that is not the case. The definition of a template is a gauge, pattern, or mold used as a guide to the form of a piece being made.
Design patterns do something similar, but not exactly the same as a template. A “blueprint” is a much better term that fits the description of a design pattern because a blueprint is a step back from a template in the sense that before knowing even how to make the template, you need to have an idea of what you want to build first. It lays out a map of how things could be built but doesn’t explicitly state how to do so.
In a programmer’s mind, the “blueprint,” say, for example, an algorithm, would be the pseudocode or diagram (graphs, trees, etc.) of the problem that you are trying to solve, and the “template” would be the implementation via some data structure in a programming language or an action similar to it. The “blueprint” is the conceptual process, while the “template” is part of a more concrete process. I am currently taking an Algorithms class and our curriculum happily intertwines with design patterns because diagrams, which we can draw with shapes, arrows, and numbers or letters floating in the air on paper, are exactly what our “blueprints” are. Once we create our blueprints, we are able to move on to the process of writing pseudocode, which, in that case, is our “template.”
This idea of reusing a solution to a commonly occurring problem seems like a very obvious thing to do, and thankfully, it is something that we as humans have learned to do dutifully and diligently. Documenting our problems and solutions has become a foundation in learning for the newer generation, and design patterns are a fundamental concept to learn even when you don’t know how to code. There is the saying that goes, “If it ain’t broke, don’t fix it,” and that saying is definitely tried and true.