Patterning in Software Design
02 Dec 2021
Introduction
Design patterns are solutions that can be applied to common problems repeatedly. This is why design patterns are sometimes referred to as templates because templates give the building blocks for developing custom wepbages. As a building block, a template provides the standard way of beginning to approach a problem. This prevents the user from making simple mistakes that could slow down the development of the program and improves the readability of the code. Design patterns also tend to use common names for software interactions, making it easier to communicate and collaborate with other developers. As described in the 314 video lecture on Design Patterns, there can be multiple approaches to a solution, but there are better approaches that are more efficient, cheaper and less time consuming. Depending on a geographical location, particular community or usage case, one design pattern might be preferred over the other - even if they are essentially solving the same type of problem.
Main Types of Object Oriented Design Patterns
In objected oriented programming, there are three main cateogries of design patterns: 1) Creational Patterns (creating objects), 2) Structural Patterns (how collections of objects are represented) and 3) Behavioral Patterns (the management of interactions between objects). There are 23 classic software design patterns that fall within these categories. Popular patterns such as “Factory” and “Singleton” fall within the Creational category. The “Observer” pattern belongs to the Behavioral category. Model-view-controller (MVC) is another popular pattern that does not fall within these categories and is a compound pattern.
Factory methods allow for returning subclasses of a generic class. A singleton class can only return one instance. An observer design pattern involes a one-to-many relationship between objects. The dependent objects are the observers so that when the subject changes state, then all of the observers are notified and updated. With MVC, the model is the data and the view is what creates the visual representation of the data. The controller handles the updating of the view as the data is modified. So, the controller keeps the view and the model separate.
Design Patterns in 314
In 314, we made use of Model-View-Controller where the MongoDB database served as the model and HTML along with Semantic UI provided the view. React was used as the controller that gets data from the model and makes it available for the view.
We also used the Publish-Subscribe Design Pattern that has a similar function to the Observer pattern when we used Meteor. In Bowfolios for example, we used a publish method to create a Meteor publication giving a cursor to the contents of an entire collection. Only when the code was run on the server side, was the publish method called. The Bowfolio Profiles needed to have this information however, so for the client, we called a Meteor subscribe method to get that information.
The observer design pattern could also be seen where the observer is code that is tied to a Reactive variable or Reactive Dictionary. Whenever a change occurs in the MongoDB database, the observing code will be re-run to reflect the change in state.
We used a front controller design pattern (FlowRouter) to handle the authentication and logging in of users to Bowfolios and Digits.
In my group’s Kahukai application, an example of the observer pattern is where clicking on a picture (eg. bird or turtle) changes the state. The click handling function observes the event of the state changing and uses this to fill in the value of a text field.
Another example of an observer pattern in the Kahukai application involved keeping track of a state that determines whether a map (used to determine the location coordinates) should be displayed or not. Clicking on a button changes the state so that the map gets displayed. The code used to display or hide the map is an example of an observer.