I’ve only been an ICS major for 2 years, but the words “design pattern” had never reached my ears before the start of the design patterns module. When I first heard about them, I just assumed they meant the way the code was displayed to a user like most web page having a navbar and a footer or something. After watching the screen casts and looking back at some of the projects that we worked on earlier in the semester, I can say that design patterns are much more high level than that. Content that is displayed on a web page is only a single example of a design pattern, but my original perspective was too narrow. Design patterns are not only limited to front end user interfaces, but can also include back end logic. From what I got from the first screencast, design patterns are just general solutions to common problems that occur in software engineering that can be modified to be applied to actual code. A design pattern introduced in that screencast that I found interesting was the MVC (Model-View-Controller) since it was said that anyone who had worked on a website has already worked with it. The model is what is stored in the backend like the database and logical code, the view is what is actually displayed to the user, and the controller is what changes the view depending on user input and model directions. Pretty much everyone knows what the view is since that is what is displayed to the user in a web page or other application. The model and controller parts are known by anyone what has ever written code before. I think it’s interesting how just about every website I’ve ever been to has followed this design pattern, just a little modified to fit their theme.
After never hearing of a design pattern before, I was surprised to learn that I had already been using them for years. Ever since I started writing code as a computer science student, I have been unknowingly making use of design patterns. One specific design pattern that we’ve used this semester is the observer pattern as implemented by Meteor’s publish-subscribe model in the meteor-template-application-react, BowFolios, digits, and most recently my group’s final project Over Da Rainbow. Whenever something is changed in the database (insertion, update, or deletion) it gets published. Then the pages that depend on the database subscribe to the newly changed database and the page is updated to display the change. Even though this seems like a basic functionality all websites should have, it would be impossible without the observer design pattern. Another important design pattern that I’ve been using without noticing in those same projects is the MVC to keep backend separate from the view displayed to the user. In the meteor-application-template-react activities, the user was only shown the “stuff” that was owned by them using the model-view-controller design pattern. The “model” is the database, specifically the stuff collection in this case that holds all the stuff in the entire website regardless of owner. The controller determines the currently signed in user’s username and searches for the stuff that is owned by that username. Finally, the view displays only those stuff items that were found to be owned by the username that is currently logged in. These were examples of design patterns that I have implemented this semester, but over the few years I have been working with coding and computer science, I have been using design patterns the entire time.