I’ve been on many collaborative teams and strategizing or developing an overall design for a project is probably one of the most difficult aspects of the project. Not only does the skeleton of the project need to be created, but you must also consider possible problems that you might stumble across along the way and how to resolve them. Luckily, there are a number of established software engineering design patterns you may choose from to aid you and your team in developing project guidelines that best fits your project’s needs.
There are three main software engineering design patterns you can choose from:
The creation design pattern focuses on class instantiation or the creation of objects of the class type. This design method aims to reduce any unwanted design complexity by properly controlling the objects created.
The structural design pattern aims to simplify the design process by understanding the relationships between entities. This design strategy can be further broken down into the following design patterns: decorator and proxy.
You can think of the decorator design pattern as functioning similar to that of applying decorations to a Christmas tree. For example, there are many decorations you can add to a tree: lights, ornaments, the star on top of the tree, snow, garland, etc. Each decoration had additional functionality—for example, controlling the on/off switch of the lights.
The proxy design pattern creates a place holder for objects that require a lot of resources. For example, let’s say you want to purchase an item but you have all of your cash in your bank account. You can write out a check to take the place of money you have in your bank for the time being so that you may purchase the item.
Lastly there are behavioral design patterns which identifies and utilizes communication patterns between objects. There are two types of behavioral design patterns you can consider: interpreter or state.
The interpreter design pattern maybe described as a strategy that takes input, interprets it, then outputs the translation as useful results. For example, you can think of a musician as the interpreter who can read sheet music and translate those notes into actual pitches and sounds represented by sheet music.
The state design pattern may be used to control the state of a function and the internal state changes allow certain actions to take place. For example, vending machines can have different states depending on whether money was deposited, inventory, whether change must be returned, etc.
For my software engineering I course during the spring of 2018 my team members: Brian Hoole, Chaster Mateo, Yubi Peterson and myself, Victoria Soto were tasked with developing an application that assists users at UH Manoa in locating various food options available to them on campus. We collectively agreed upon the name Grub ‘N’ Go.
I’ll be honest—neither one of my team members nor I considered specific design when organizing the structure of our application. However, after looking back at the code, we did (unintentionally) incorporate some of the design patterns I discussed above. This could be due to the fact that we’ve been sort of hardwired to design in a certain way from the classes we’ve taken.
The design patterns we’ve incorporated include the: decorator, interpreter, and state. For Grub ‘N’ Go, the decorator maybe viewed as favored vendors a user could add to their profile or changes a vendor may make to their menu by adding or removing menu items. The interpreter and state designs were implemented throughout the entire application and occurred simultaneously. Essentially anytime there was a state change, input was received, interpreted, then the output was translated as a result.
For example, upon visiting Grub ‘N’ Go website you can choose to sign in or register—depending upon the option you choose, you’ll be directed to the appropriate web pages. In this case, the input is interpreted, will cause a state change, then the change of state will result in a translated/interpreted output. These patterns are seen throughout Grub ‘N’ Go from logging in/out to adding favorite vendors, to modifying menu items.
Although my team and I did not specifically seek out design patterns to implement, we incorporated the decorator, interpreter, and state design patterns out of habit from coding practices we’ve learned in our courses. :)