Design patterns

August, 2022

Patterns are trusted recipes used to solve recurring problems. They are models used to guide the development of solutions to the kind of problems software engineers face everyday in their work. You may ask: why the hell do you need to learn about design patterns. I will help answer the question with some reasons based off my personal experience:

  1. Design patterns will help you recognize a set of similar problems whenever you see them.
  2. It will help you know the solutions that best solve these set of problems when you encounter them
  3. Design patterns will help you in writing clean, DRY and extensible code as your solution would fit well into the problem it's trying to solve.
  4. Design patterns would help in conversations with your teammates and people you meet in your career journey as you all can have a shared lingo to express ways of solving problems
  5. Design patterns would help you solve problems "once" as you use the right tool (right design pattern) to solve a problem right from the onset.
  6. Leveraging design patterns in problem solving would make your code a joy to work with as your colleagues would like to and also find it easy to maintain code that you worked on.

Now that I've shared some of the personal reasons why we need to learn about design patterns, I will try to share example problems that certain design patterns can help us solve. Imagine building a class where some other classes are interested in the changes that happen in this your class. Straightforward thinking says, couple the classes together so that they can be close to the source of data changes.
However, design patterns teaches us about observers. We could create an observer within the class for which other classes are interested in its changes and then have the interested classes register their interest in the observer. When our class eventually changes, our class observer notifies all the other interested classes and if possible provides the classes with snapshots of the before and after states of our class data.
Also, sometimes, we don't want direct access to our classes or we want to hide our API implementation from the consumers, imperative thinking will be to reimplement our class or API and use that as a cover for original API or class. However, with the proxy pattern we can have a framework for solving this kind of problems by encapsulating the class of interest inside a proxy and have other interested parties access it via the proxy.

Some real life examples of design patterns that we use in our everyday work are:

  • Event listeners in the browser: the one onEvent framework used in browsers is a perfect candidate for marketing the beauty of the observer pattern. On the browser, we can register multiple functions that are interested in certain actions (events) being carried out by users on a browser. We can register functions for when a button is clicked or when a form is submitted. These functions can then use that context to execute any logical action of their choice.
  • Class inheritance in object-oriented languages: in object oriented languages like Java, sub classes can inherit from their parent classes thereby giving them the power to utilise, extend and modify the functions/methods already implemented by the parent classes. The design pattern behind this is the template pattern. The template pattern is like the prototype in factories from mass products and varieties are made from.
  • SQL language: developers, DBAs, data analyst and even excel wranglers use a common language to access data stored deep in databases. The design pattern behind SQL is the domain specific language pattern. It is built around the idea that certain fields require languages that best suit their lingo and transcribing information from these languages to the machine to understand would give users better experience while trying to achieve their tasks.

In conclusion, design patterns are a great tool in any software engineer's toolbox as they are a sure way to write clean, DRY, extensible and easy to maintain code. They also help us to box problems into frameworks from which they can be easily solved which invariably makes our job easier ie: our job becomes more of finding the interactions between state, behavior and other 3rd parties and the design patterns that best model/solve the problem would evolve accordingly. To learn more about design patterns, read the book: Design patterns in Ruby by Russ Olsen. Hopefully, I've succeeded in stirring your interest towards seeing the need to learn about design patterns. Go into the world and explore.