The History of Design Patterns
Design Patterns were introduced in a book called Design Patterns – Elements of Reusable Object-Oriented Software. The authors Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides became famously known as the Gang of Four(GoF). Although that was the first time the patterns were documented, GoF mentioned in the Introduction that expert object-oriented designers have been using them for years.
The book mentions that not all existing Design Patterns are documented. There are many more Design Patterns in the heads and notes of other experts.
Despite the book’s size, the design patterns in it capture only a fraction of what an expert might know. It doesn’t have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn’t have any application domain-specific patterns.
– Design Patterns, GoF, 1995
What are Design Patterns?
A Design Pattern is a pattern that gives us a clear template for solving, generally speaking, similar problems in different ways.
For example, we know we need at least four walls, a roof, and an entry when building a house. The template would be how we place those items together while the requirements are the items required. Although we can create many homes following the same template, we don’t all have to construct them of the same material.
A Design Patterns has four elements:
- The pattern name – The pattern name allows us to talk about the designs abstractly with other developers without the need to explain what we all already know.
- The problem – The problem describes when to apply the problem and explains its context. Sometimes the problem will include a list of conditions that must be met before it makes sense to use the pattern.
- The solution – The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations.
- The consequences – The consequences are the trade-offs. Software architecture is all about trade-offs, and design patterns are no exception. We have to understand the trade-offs before deciding if the trade-offs are worth implementing the pattern.
A Design Pattern will fall into one of three categories; creational, structural, or behavioral. All of which we will be digging into in the course.
Why are Design Patterns important?
Design Patterns are essential because it allows us to solve complex problems without re-inventing the wheel. We, software engineers, benefit from learning and understanding these Design Patterns because they’re used across multiple frameworks, libraries, and companies. We will better understand the problem others are trying to solve and how they plan on solving it when we hear “Adapter” or “Flyweight.”
In this course:
We will break up the course into three sections for each Design Pattern Category. Each Design Pattern will have its lesson, and each lesson will include the reason behind the pattern, the problem it will solve, the implementation, the pros and cons, and an example through code or a UML diagram.