Patterns Shmatterns

26 Nov 2022

Why it matters

Design Project Mayhem

Despite experiencing numerous assignment, programs, projects, and essays during my time in university, it never fails to surprise me how I can make completing my work more difficult than it should be. I sometimes have a tendency to start writing a paper from top to bottom, even if there are sections below I can complete quicker or write computer programs without thinking of an algorithm first. These are all examples of me failing to utilize study and work patterns that have kept me successful in turning in quality work. Things such as getting enough rest, taking proper notes, eating a healthy diet and exercising also play an important role in my efficiency. Similarly, in the world of computers, we can utilize tried and proven design patterns that prevent us from "Reinventing the wheel" everytime we work on a problem. In the next few sections we will discuss some of these design patterns in detail.

Common Design Patterns

The term Design Patterns was defined in 1977 by an architect of the name Christopher Alexander in his book, A Pattern Language . He described it as a problem that occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. This definition was profound in that despite having a new problem, though not necessarily identical to an old one you’ve encountered, the older solutions can be used to as a template or guide to how tackling the problem can be structured. A simple example would be the type of roofs built in an environment such as Alaska. Although weather can vary geographically, common sense and experience would tell us that flat roofs would not do well in a snowy environment where pointy roofs are much more reasonable against the weather.

In terms of software design, A group of software developers, inspired by Christopher Alexander’s views on design patterns, published a book on software development patterns. They would later be famously dubbed as the Gang of Four. The 23 patterns the authors/developers identified could be broken into three types: Creational, Structural, and Behavioral. Like the the roofs in Alaska, we can identify patterns in our programming objective that can help us find the right solution.

Creational

Provides different ways to create an object.
Structural

Provides relationships between objects.
Behavioral

Provides how objects interact or communicate with one another.

Above are the types of design patterns for object oriented programming and their definition. Below is a table of the Patterns defined by the Gang of Four and summarized in an blog post by Ela Singh.

Creational Design Pattern	Description
Abstract Factory	Allows the creation of objects without specifying their concrete type.
Builder	Uses to create complex objects.
Factory Method	Creates objects without specifying the exact class to create.
Prototype	Creates a new object from an existing object.
Singleton	Ensures only one instance of an object is created

Structural	Description
Adapter	Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.
Bridge	Decouples an abstraction so two classes can vary independently.
Composite	Takes a group of objects into a single object.
Decorator	Allows for an object’s behavior to be extended dynamically at run time.
Facade	Provides a simple interface to a more complex underlying object.
Flyweight	Reduces the cost of complex object models.
Proxy	Provides a placeholder interface to an underlying object to control access, reduce cost, or reduce complexity.

Behavioral	Description
Interpreter	Implements a specialized language.
Chain of Responsibility	Delegates commands to a chain of processing objects.
Command	Creates objects which encapsulate actions and parameters.
Iterator	Accesses the elements of an object sequentially without exposing its underlying representation.
Mediator	Allows loose coupling between classes by being the only class that has detailed knowledge of their methods
Memento	Provides the ability to restore an object to its previous state.
Observer	Is a publish/subscribe pattern which allows a number of observer objects to see an event.
State	Allows an object to alter its behavior when its internal state changes.
Strategy	Allows one of a family of algorithms to be selected on-the-fly at run-time.
Template Method	Defines the skeleton of an algorithm as an abstract class, allowing its sub-classes to provide concrete behavior.
Visitor	Separates an algorithm from an object structure by moving the hierarchy of methods into one object.

Putting Patterns to Practice

At a glance, I did not think I was familiar with any of the design patterns listed by the Authors. After all, my experience with object oriented programming is rather short for a computer engineering student. However, after closer inspection, I was surprised to find I counted myself out too early. In terms of Creational design, I recall creating a program which utilized a factory pattern for creating various animals for an animal farm. It makes sense that we used a factory method rather than creating each object by hand. However, it was difficult for me to grasp that concept and is still not completely clear to me. For Structural patterns, I have yet to use or come across this pattern, but I can see it being very helpful. Lastly, Behavioral. During this software development course, I was introduced to handling events, subscribers, and publishers for meteor collections which are directly related to Observer patterns.

More Patterns and Beyond

Besides the 23 patterns listed above, there are more patterns that have been useful to specific languages such as Javascript as listed in the the Patterns.dev site. While older patterns such as flyweight, proxy, and command are still often seen and used, we see the emergence of newer patterns such as hooks introduced in the react library for reusing stateful logic, tree shaking for reducing bundle size by eliminating dead code, progressive hydration to delay loading of less important parts of pages and much more. I have no doubt that as I continue to code and grow as a developer, I will come to know and rely on these patterns more than not as I do with all patterns in my life. As the theoretical physicist Fritjof Capra one said, The understanding of life begins with the understanding of patterns.