What are the Benefits of Design Patterns?
25 Apr 2024
Design Patterns in 314
In ICS 314, we were introduced to a handful of design patterns for the very first time. Seeing patterns and formats through the default meteor template, bowfolios, digits, as well as a handful of patterns used for the WODs. These patterns are incredibly useful going forward because they could be repurposed for a lot of the upcoming experiences. Even being helpful in providing a basis for the final project. Simple aspects like the navbar, sign-in/sign-up, and landing page are useful in almost every application we’ve made so far and are vital in applications going foward. I can easily see using these designs outside of class for future projects. Within 314 they’ve been vital to consistent and convienent starting points. It was pretty much encouraged for the latter half of the WODs to have these prepared. It saved potentially hours of setup time which allowed WOD takers to focus primarily on the WODs requirements instead of the initial setup. On top of this, because we were given a plethora of design patterns, we had many options to choose from depending on the requirments of the assingment. Like Island Snow being useful for any following Island Snow WODs and experiences, ie a simple landing page with a background, header, navbar, and footer. In that case there was no need for something like Bowfolios which has a little too much meat on its bones for the earlier applications. Overall this just displays the versatility of the design patterns used in 314, and how the choice of design pattern played a big role in optimizing developer productivity.
How do they Benefit Developers?
As stated previously, design patterns offer simple problem solving and solutions during the development and app creation process. Being that they essentially starting blueprints to follow that vastly improve the efficiency and reliability of a developer’s code. Let’s give a common example, working with a team or even multiple teams. If you assigned guidelines for the teams to follow, they will probably all follow them, but there is a low chance that they will follow it the same way. This is especially problematic if each team has a page or pages of the application to work on. Layouts, components, and styles may differ massively. Causing inconsistencies in the code that would prevent teams from being able to work on anything outside their assigned pages. Or even worse an incosistent experience for the user. By utilizing design patterns, developers can share a structure that prevents these seemingly subtle differences from evolving into massive inconsistencies across the board that negatively impact user experience. A common pattern like the Factory Pattern is a great simple example of this. There’s no need to reinvent the wheel so if everyone assigned to the project is given the guidelines to implement some aspect of user database, they can all reference the same design pattern so as to not have too varying aspects of database.
My Experience
The benefits of design patterns in software developement, while seemingly minimal actually provide a multitude of pros that not only affect productivity but also convienence. From my experience in ICS 314 they’ve served as useful tools for solving recurring problems while also being the foundations of the application that aided in efficient, scalable, and maintainable code. Goind back to the final project for the semester, our design is based on a design pattern named digits. While seemingly simple, our entire team had experience with it so it made comprehension very easy. When creating the Github issues and milestones it made it very convienent to tackle all the code related issues. For us, that meant we could focus less time on the simple structural aspects of the project and focus more on the complex additions we were making. Like our new database, pages, etc. It was nice not having to waste much time on getting the page initially up and running and allowing us to collaborate on the necesarry changes we need to make, instead of initial additions just to get the application started. It felt great having a standardized starting point, and in my opinion allowed us to work more cohesively and efficiently. I think that the final project is a great starter example of pointing out the necessity of design patterns, and going forward into my professional career even if I do not pursue network based applications, I still see design patterns as a very useful means in all developmental projects.