Over the course of their life, everyone runs into some problems that just keep cropping up. No matter what it is you’re doing or how long it’s been since you last ran into them, these problems just keep coming back. However, even if it can be annoying to run into the same problem over and over again, as you’ve dealt with it more it can almost become like an old friend. While the solutions to that problem will likely come in a myriad of variations depending on the context surrounding each instance of it, as you run into that same problem over and over again you will likely come up with a general set of ideas that form the gist of an actionable solution to the problem. Even though the specifics of your solutions change depending on how the problem presents itself and you’ll always end up having to put in the work to create a solution using those concepts, just having that solid set of steps to start with can be an absolute life-saver.
In life generally we generally just chalk that knowledge up to experience, but in a situation where said problems have more definite solutions, the concept becomes even more relevant. As such, in the field of software engineering, where the solutions to problems are like watches comprising thousands of tiny clockwork components, all ticking in time with each other, you’re likely to run into some of the same sub-problems over and over again in everything you do. As such, these basic blueprints for the starts of solutions are extremely relevant, and have come to be called design patterns. Design patterns are more than just algorithms – while algorithms are designed as a tangible, provable solution to a single problem, design patterns are more of a set of concepts which are generally applicable to a class of problems and are useful to help streamline the process of designing an algorithm to solve a specific problem.
However, ultimately, even if the name of “design patterns” hasn’t always been around, the idea is one intrinsic to the learning process in general, and has always been around. I myself hadn’t really thought much about them until I began studying them recently in my ICS 314 class, however a I’ve learned more about them I’ve come to find that there are examples of them strewn throughout much of the code I’ve worked on. There is an extent to which that comes from being taught code in a structured manner by those who have spent the time doing this more abstract analysis of the process of problem solving, however I’ve also come to instinctively apply them in the programs I’ve made of my own accord, simply due to the experience I’ve gained coding over time and my discovery of what works, what doesn’t, and what makes the experience of coding more pleasant and efficient. For example, my most recent project as of writing this is a web application called Roommate Radar, the details for which can be found at https://roommate-radar.github.io. While the app is very clearly the work of novices, it’s still a complex system full of many moving parts, and I’ve proud of all the work my group and I have put into it. Upon learning about design patterns, I’ve taken another look at the work we’ve down through that lens, and the examples present are many and varied. Amongst a few that I immediately recognized, we’ve used Singletons for our MongoDB collections, States for our forms, Publications and Subscriptions to pass around the data from our MongoDB collections, and many, many more. Even if the idea of labelling what kinds of patterns each and every line of code your write fall under sounds absolutely exhausting, it’s honestly quite refreshing to be able to put a name to concepts that you already have floating around your head. Even though the ideas were there before, just seeing them put into words has made them all the more tangible to me.
Furthermore, it’s rather interesting noting the differences between how they’ve ended up present in the code – when creating things, it’s only natural to depend on the work others have put in before you – that may take the form of a specific package or library that you use, but even if you’re coding the most minimalist project ever, the language you’re writing in, the editor you’re using, everything about your code didn’t just spontaneously appear. Someone had to make it, and generally that someone (or those someones) are interested in helping users to create the best work they can. As such, I’ve found that in many instances there are design patterns relating to concepts I’d never thought of present in my code, because those that came before put that thought in. It’s very cozy to think of the effort that those that came before put in to help out those of us who have come after. I’m sure it must have taken countless hours and a great amount of mental energy to do so, and in many ways I feel like these contributions can easily go unnoticed, but this act of sharing knowledge to help those that come later, even if not at any particular benefit to yourself, is both great and tender. It’s just one of those things that just makes us human.