A Stumble onto Design Patterns

I often times find myself watching programming content on YouTube. On one such occasion several months ago, I was watching a reaction video to 8 Useful Design Patterns, which started with the following quote from the original video:

I heard you liked factories, so I made you a factory inside a factory, which inherits from an abstract factory, so it can create new factories.

This wasn’t the first time I’ve heard of the term “design pattern.” I knew that it involved patterns regarding design - particularly in object-oriented codebases. Yet, I found myself mildly confused. Why was the factory (which I assumed was an example of a design pattern) inside a factory from an abstract factory used to make new factories? Was it normal to have an abstract factory have a child factory which made more factories?

My opinion on design patterns fell a bit. It wasn’t until recently did I start to take a closer look at design patterns, thanks to my ICS course that I’ve been taking to supplement my ECE major. Kind of funny how this thing that kept on appearing in front of me every so often eventually made its way to the stage and gained my full attention. Perhaps this topic would like to redeem itself in my eyes, as well as the eyes of anyone who reads this.

An Understanding of Design Patterns from an ECE Student

Being an electrical and computer engineering student, I’ve never had to dive deep into this topic, as it was sufficient for us to understand the basics of procedural and OOP paradigms of programming. I did understand that there were certain things that would appear over and over again, so much to the point that I’d come up with weird names for those repeating things.

Consider the following example in Python:

from sympy import symbols, solve, latex
from os import system

a, b, c, x = symbols('a, b, c, x')  # Variables
expr = a*x**2 + b*x + c  # Equation equal to zero
sol = solve(expr, x)  # Solve
system(f'{latex(sol)} | pbcopy')  # Copy LaTeX solution to clipboard on MacOS

I call it the “SymPy solver,” since it follows the same boilerplate pattern of creating variables, creating an equation, solving the equation, then copying the result to the system clipboard in LaTeX for me to paste into my problem set submission. I’ve been using this approach for at least a year.

Now, this is less of a design pattern and more of a program with a few lines that change every so often depending on the requirements, but this repeated observation definitely conforms to a pattern… that affects the design of a program. This repeated pattern was put out to solve a specific problem in a specific way. Perhaps the purpose of design patterns is to provide knowledge of known solutions to known problems?

The Definition and Purpose of a Design Pattern from Software Engineers

In the introduction of the influential book Design Patterns: Elements of Reusable Object-Oriented Software, the authors state the following in the book’s introduction:

The purpose of this book is to record experience in designing object-oriented software as design patterns. Each design pattern systematically names, explains, and evaluates an important and recurring design in object-oriented systems.

The introduction continues and clarifies the purpose of a design pattern in a succinct fashion:

Put simply, design patterns help a designer get a design "right" faster.

This is in line with what I suspected earlier: design patterns provide knowledge of known solutions to known problems to “help a designer get a design ‘right’ faster.” However, I’d like to add on another quote from the illustrious Uncle Bob from an interview he had:

If you're sitting there, reading code, and you see "Oh, this is the 'XYZ' decorator," and you happen to know the decorator pattern, then the structure snaps into your brain, and you don't have to work it out by reading the code perfectly. That's the whole point of design patterns: to [see if there's] a way to take one notch up on the level of abstraction, so that you can look at things in the code and identify them without having to go line, by line, by line, by line.

This generalization of a design pattern is what I find to be the most appealing: it’s a way to abstract common occurrences in a way that makes things easier to understand and - in some cases - solve.

“If I Haven’t Been Taught Design Patterns, Does It Mean They Don’t Exist Anymore?”

Not at all. Design patterns weren’t things whisked into existence, but things that have always been around to the point that they were documented. Even in the example web application I’m working on in class, there are multiple examples of design patterns present in the codebase. Here are a few examples.

• From the original book, the strategy pattern is implemented by “[d]efin[ing] a family of algorithms, encapsulat[ing] each one, and mak[ing] them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” This essentially employs interfaces and lets the interfaces change beneath the hood. Think of how the frontend can stay unchanged while the backend is allowed to modify what happens “under the hood” - assuming it keeps its interface to the frontend constant.
• The iterator pattern shouldn’t need any introduction: it gets used whenever a collection class has a .next().
• The adapter pattern uses an object to “connect” two otherwise incompatible interfaces. It can sometimes be used as a hack and add a middleman to the operations, but comes off as very useful - especially when you don’t know how to modify the underlying code but understand the interface presented by the code.
• The bridge pattern decouples abstraction from implementation. Considered whenever doing object-oriented programming or working with model-view controllers to let users use applications with zero understanding of the underlying codebase.

Design patterns are ubiquitous and will always exist.

“Will I Be a Terrible Software Developer if I Don’t Read the Book on Design Patterns?”

I don’t think so, but it surely wouldn’t hurt to give it a try! I’m not a software developer, but I plan on reading through that book because Uncle Bob was right: moving one level of abstraction up really does help understand what’s going on.