There is always a point in one’s educational journey, whether it’s in 10th grade English or a software engineering course many years down the line, where he learns of a practice that is something he’s been implementing for years without knowing it. This realization either complicates everything he thought he knew about the subject, or makes it monumentally easier. In my case, when I first read about design patterns I thought that I had clicked on the wrong link and was reading an article that could’ve been titled “15 of the Most Broad Statements about Computer Science.” I was dumbfounded that there was an actual study based around this kind of thing, as I had been implementing many of these patterns simply because it is what I’ve always done.
Everything that I included in my old projects, such as helper methods used to deconstruct a problem so the function could be used in a less specific sense, creating prototypes to test how new functions effect the larger system, and iterating through large collections to extract specific data were all examples of design patterns. Design patterns to computer science aren’t exactly like equations to physics, but more like the laws governing them. They are something that when one takes a step back to truly observe the structure of their situation, he can see veins flowing through, connecting and reconnecting even without one’s conscious intention. Design patterns occur in naturally solid code, which is the sign of a efficient programmer. Needless to say, I was shocked when I saw such examples in my own code, which I until recently thought could have been replicated by an elephant with a paintbrush and a strong breeze. As proven to me again and again throughout my journey through the terrifying yet glorious landscape of computer science, there is always more to observe. There is always more to learn.