A design pattern is a reusable solution to a common software design problem. It is not a block of code to copy, but a well-known way to organize classes, objects, and responsibilities.
When we start programming, our main concern is simply “making the code work.” But as our projects grow, we realize that making it work is not enough. The code becomes difficult to maintain, rigid, and fragile.
That’s what design patterns are for. They are not code themselves, but proven solutions to recurring problems in software development.
In this course, we will look at the most important patterns, explained “for human beings,” and how to implement them in C# and C++. Before diving into the code, we need to understand exactly what they are and where they come from.
What is a Design Pattern
A design pattern is a description of a solution to a common problem that occurs when designing software.
Think about the design of a building. If you need to create a door for people to enter and exit, you don’t reinvent the concept of a “door,” with its hinges and knob, every time. You use a known solution.
The same thing happens in programming. A pattern is not a library or a framework that you can import. It’s a concept, a template for how to solve a problem, which we have to adapt to our code.
A design pattern is a general and reusable solution to a problem that occurs frequently within a given context in software design.
Using patterns helps us:
- Avoid reinventing the wheel: we use solutions that have already proven to be effective.
- Speak a common language: we summarize the intent of the design with a well-known name.
If I tell you “I used a Singleton here for the database connection” or “we need an Observer for the UI,” we understand each other instantly. I don’t need to explain 200 lines of code; with a single word, I’ve conveyed the design intent.
A Bit of History: The Gang of Four (GoF)
Although it might seem purely computer-related, the original concept comes from traditional architecture. In 1977, Christopher Alexander wrote about patterns in buildings and cities.
However, in the software world, the “bible” arrived in 1994 with the book “Design Patterns: Elements of Reusable Object-Oriented Software.”
This book was written by four authors: Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. In our industry, this group is affectionately known as the Gang of Four (GoF).
They compiled and described 23 design patterns that shaped object-oriented programming. Languages have evolved a lot since 1994, and some patterns are now built into their own constructs, but the vocabulary and the problems they describe are still useful.
Structure of a Pattern
To study a pattern, it’s not enough to look at the code. In this course, when we analyze each pattern, we will always look at four key points:
- The Problem: what headache it tries to solve.
- The Solution: the elements that form the design, their relationships and responsibilities (usually with a UML diagram).
- The Example: how it is implemented in C# and C++.
- The Consequences: what we gain and, very importantly, what we lose when using it.
Classification of Patterns
The GoF classified patterns into three broad categories, depending on their purpose. We will follow this same structure in the course:
They deal with object instantiation. They help us make a system independent of how its objects are created, composed, and represented.
- Examples: Singleton, Factory Method, Builder.
They deal with how classes and objects are composed to form larger structures. They help ensure that if one part of the system changes, it doesn’t break everything else.
- Examples: Adapter, Decorator, Facade.
They focus on the assignment of responsibilities between objects and how they communicate with each other. They describe not only patterns of objects or classes but also the patterns of communication between them.
- Examples: Strategy, Observer, Iterator.
The Dark Side: When Not to Use Patterns
This is perhaps the most important part of this introductory article. There is a phase that all programmers go through, which I call the “Pattern Fever.”
It happens when you’ve just finished reading the GoF book (or this course) and suddenly you want to use patterns everywhere. You’re going to write a “Hello World” and you throw in an Abstract Factory with a Singleton and a Decorator.
Beware of over-engineering! Design patterns add complexity. If the problem is simple, the solution should be simple.
Don’t use a pattern just because “it looks elegant.” Use it because you have a real problem that this pattern solves.
Abusing patterns leads to unnecessarily complex code that is hard to understand and debug. As the saying goes: “If the only tool you have is a hammer, everything looks like a nail.”
Throughout this course, we will break down the patterns one by one. Before diving into the code, we need to review a visual tool that we’ll use constantly to explain their structure.
