Has the sunlight ever bothered you while driving, walking, watching a game, or simply when going outside? I think we all know what that’s like, but, how do we usually tackle that problem? Hats, sunglasses and even our own hands are common alternatives that, if you think about it, are based around the same simple solution: use the shadow of an object to stop the light from hitting your eyes.
Design patterns are Object-Oriented tools that can be used in a similar way. When a developer faces a problem it’s a common solution to seek some help on the Internet, why? Because there’s a high chance that someone else has had the exact same problem before, and probably a solution has already been provided.
Design patterns are references, templates that show a standard solution for a problem. They, unlike stackoverflow’s answers, only tell you what the solution to a specific problem is, and don’t include any kind of implementation or information on how to do it. More specifically, design patterns usually have some kind of structure: they have identifiers (names), the problem they’re solving, the detailed solution and, sometimes, tips for implementation and possible consequences of their use.
They are usually considered good practices, since they’re not arbitrary solutions, but well-thought and well-defined alternatives. That’s why it’s recommended to completely understand how they solve the problem and why it works instead of just learning methods and classes.
The concept of design patterns (at least when talking about software) became popular when the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) published a book in 1994 called ‘Design Patterns: Elements of Reusable Object-Oriented Software’, where they classified and described 23 different design patterns that could solve recurrent problems in programming.
Their classification consisted of three groups, with each one covering a different aspect of OOP. I will list the three categories and give an example of one of the corresponding design patterns.
First, we have creational patterns, which are related to instantiation and creation of objects and classes and how to manage these processes. These patterns control how new objects should be created and managed, some even define how many instances of certain class should exist at the same time. Speaking of which, the singleton pattern describes a way of having only one instance of certain object at all times, ensuring that once an instance exists, no others can be created.
Structural patterns help define relationships between objects. They usually dictate how two classes work together in the sense of what one represents to the other. These patterns are useful to later simplify interactions between objects, like the adapter pattern; its implementation is what we normally know as a wrapper and it basically “translates” an object into another format so otherwise incompatible methods can work on its instances.
Finally, behavioral patterns work as guides to establish how two or more objects interact and communicate. Usually, their goal is to delegate responsibilities so no unintentional modifications happen. The observer pattern is a way of keeping track of certain changes that happen in an associated class, when certain action occurs, the observer notifies other objects and they act accordingly. It works as a messenger.
For way more detailed information on the 23 original design patterns and concrete examples for each of them I recommend checking out this page.
To this day, the classification provided by the Gang of Four is still used. And 23 out of their 23 original suggestions are still used as standard solutions, although many others have originated since. As it happens in many other fields, there are new suggested categories and patterns, and, of course, criticism towards the original patterns have come up ever since they were first published.
A couple of things I noticed while trying to understand each pattern is that, just like in the example of wrappers I gave earlier, many concepts used in OOP probably originated from design patterns, and some of them even are taken as the best practices for some situations. Also, after reading the benefits section of this website, a particular statement stuck in my mind: understanding how each design pattern works instead of memorizing their implementation not only reinforces OOP concepts, as I said in the fourth paragraph, but it improves communication too, and as I said in my previous mastery entry, communication is key to an efficient teamwork. Knowing what others are talking about when just mentioning the name of a pattern saves time from explanations.
Tools like design patterns have lasted for as long as they have because they work, and they work pretty well. It amazes me how good and simple some solutions can be and, since their focus is OOP, I think they’re the thing I can get the most of among the topics of the course so far.
TL;DR: Efficient solutions are efficient.