As a budding software engineer develops their skills there comes a certain point where it becomes important to transition from learning about the purely functional aspects of programming, to the more theoretical aspects. I feel I am somewhere in this transitionary phase, certainly not a technical master, but to a point where I feel it is important to not just learn how to code, but to learn how to code the right way. Design patterns are certainly part of this transition. Design patterns are repeatable solutions to common problems occuring in software engineering. The patterns act as a sort of outline, which can then be implemented, often across an array of different languages. It’s suprising learning about design patterns, how often programmers will come to the same conclusions and they implement them without knowing the underlying theory. It goes to show how essential they can be, that though they will implemented with or without the knowledge behind it, once you actually go to study them you can add on top of it the best practices associated with them.
As a guitarist I see a lot of similarities between the process of learning software engineering design patterns and music theory. As a novice guitarist, as with a novice software engineer, they are usually focused on learning the technical aspects of their instrument (how to press down on a fret, how to strum, etc…). Then as the user progresses it becomes necessary for them to learn aspects of music theory. Of course the guitarist could ignore any previous teachings and attempt to be completely self-taught, and after a time they would be able to work out a variety of scales and chords and how they work together. But they would be coming to the same conclusions as if they had read a book on music theory, just without knowing the names behind the theory. One can learn chord progressions and scales simply by ear, but reading extensively on music theory can teach this much faster and teach the complexities of how to work them together.
I certainly have used design patterns in my code. For example, the MVC (or Model View Controller) pattern basically lays out the entire framework for web design, which has been the main focus of ICS 314. MVC lays out the View which renders everything, the Model which encapsulates the state and the Controller which defines the applications behavior. Looking at from the point of view of React, the View can be seen as what’s being renderd, the Model as the components state, and the Controller as the underlying Javascript.