Design Patterns, Architecture of Quality Code

02 Dec 2021

Throughout the course of our academic careers, us computer science students have been using design patterns since we first took an intro to computer science class, whether that be java or python or whatever other language we first learned. Throughout ICS 314, we’ve been exposed to other design patterns as well.

When first going through the screencasts for design patterns, I really didn’t think that we had been exposed to/used any in our previous classes. After watching the videos and really getting a good grasp at what design patterns are, I realize that we’ve been using them for our academia career thus far. Upon finishing both the videos, I tried hard to think about what I could relate design patterns to and I came up with a great explanation. Design patterns are essentially just architecture for programs. If you think about it, each blueprint has a specific design that fits a certain mold and a certain job. An apartment building isn’t going to look and function the same as a bank or a grocery store will. As such, you don’t need to use the same tools or materials for every single building that you construct. Design patterns are very similar in that way. Will you always use singleton, factory, or observer design patterns? Absolutely not. They have a time and a place where they are beneficial and useful and they aren’t applicable one hundred percent of the time. Design patterns are there to make our lives easier and to also ensure that a team of software engineers can work cohesively on a project where they can see the blueprint of the program. Design patterns are solutions that we can use on many different problems. In that case, we can see design patterns just by looking at code and reading it through.

We have been using design patterns all throughout our code over the span of the entire semester. Specifically, we’ve used prototypes with classes in JS, we’ve used singletons for collections in the digits homework as well as in my teams specific application. All of these design patterns, though, have their uses when they are the most needed/useful. We don’t just use them because we need to use them. We use them because they help us understand how the code works and it gives us a solid foundation on how our code should read and run. If my team had been using different design patters, or even antipatterns, our code would be atrocious and it would look terrible. Not to mention how inefficient we would be at solving our problems. It helps us keep our team glued together as a unit where we can understand what each person is writing and how we came to that specific solution.

Design patterns aren’t just a cool tool that we use in academia. They are essential to a solid working software engineering team where we can accomplish tasks and solve problems in an efficient and easy way. It is a key element to keeping workflow quick and ultimately keeping stress and inefficiency down.