Over the last few articles, we've answered some fundamental questions.
- Why do Design Patterns exist?
- Why isn't SOLID enough?
- Why don't good designs emerge from copying code?
- What exactly is a Design Pattern?
- Why do experienced engineers recognize problems instead of memorizing pattern names?
Now we're finally ready to answer another important question.
What are these famous "23 GoF Design Patterns" everyone talks about?
Many beginners imagine they are 23 unrelated techniques that must be memorized individually.
Fortunately, that's not true.
Once you understand why they are grouped together, learning them becomes much easier.
Before the Patterns, There Was a Problem
Imagine you're building software over many years.
Every project is different.
Different industries.
Different programming languages.
Different business rules.
Yet certain design problems keep appearing.
Sometimes the challenge is:
"How should this object be created?"
Sometimes it's:
"How should these objects work together?"
Other times it's:
"How can this behavior change without rewriting existing code?"
Experienced engineers noticed something interesting.
Although projects differed, these questions kept repeating.
Instead of treating every solution as completely unique, they began organizing similar solutions into groups.
That's exactly how the GoF Design Patterns are structured.
Why the Patterns Are Divided Into Three Families
The 23 patterns aren't organized alphabetically.
They're organized by the kind of design problem they solve.
Think of visiting a hospital.
Doctors don't organize diseases alphabetically.
They organize them into categories because similar problems often require similar thinking.
Software engineering follows the same principle.
Instead of asking:
"Which pattern should I memorize first?"
We ask:
"What kind of design problem am I facing?"
The answer usually points us toward one of three families.
1. Creational Patterns
Sometimes the hardest part of a design isn't using an object.
It's deciding how that object should be created.
Imagine an e-commerce application.
Should the checkout service directly create every payment gateway?
Should object creation be centralized?
Should different products be created differently depending on configuration?
These are object creation problems.
Creational Patterns help us answer questions such as:
- Who creates an object?
- When should it be created?
- Which implementation should be instantiated?
- How can creation remain flexible as requirements evolve?
We'll explore patterns like:
- Singleton
- Factory Method
- Abstract Factory
- Builder
- Prototype
Don't worry about what each one does yet.
For now, simply remember:
Creational Patterns focus on object creation.
2. Structural Patterns
Now imagine all your objects already exist.
The next challenge appears.
How should they work together?
Suppose your application integrates with an external shipping provider.
Or maybe several existing classes need to appear as one simplified interface.
Perhaps unrelated systems must communicate without changing their internal implementations.
These are structural problems.
Structural Patterns focus on organizing relationships between objects.
They help us answer questions like:
- How should existing objects collaborate?
- How can incompatible systems work together?
- How can functionality be added without rewriting existing classes?
Some well-known Structural Patterns include:
- Adapter
- Decorator
- Facade
- Proxy
- Composite
- Bridge
Again, don't memorize them.
Just recognize the category.
Structural Patterns focus on organizing objects.
3. Behavioral Patterns
Finally, imagine your objects already exist and are connected properly.
Now another question appears.
How should they behave?
Consider an online shopping application.
Different pricing strategies.
Different notification channels.
Different order states.
Different approval workflows.
Different ways for components to communicate.
These are behavioral problems.
Behavioral Patterns focus on how objects interact, collaborate, and make decisions.
They answer questions like:
- How should behavior change?
- How should multiple objects communicate?
- How should requests flow through the system?
- How should algorithms remain interchangeable?
Examples include:
- Strategy
- Observer
- Command
- State
- Template Method
- Iterator
- Mediator
- Chain of Responsibility
- Visitor
Once again, don't worry about remembering every name.
Focus on the type of problem.
Behavioral Patterns focus on object behavior and collaboration.
A Simple Mental Model
Instead of remembering 23 independent patterns, remember three questions.
Am I struggling to create objects?
↓
Creational
Am I struggling to organize objects?
↓
Structural
Am I struggling to manage behavior between objects?
↓
Behavioral
This simple roadmap is far easier to remember than a long list of pattern names.
More importantly, it's how experienced engineers naturally think.
Weak Thinking vs Strong Thinking
Weak Thinking
"I need to memorize all 23 Design Patterns."
Strong Thinking
"First identify the type of design problem. Then explore the family of patterns designed to solve it."
The family comes before the individual pattern.
Common Beginner Mistake
Many developers print a chart of all 23 GoF patterns and try to memorize each definition.
A week later, they remember almost nothing.
Why?
Because isolated facts are difficult to retain.
Instead, build your understanding in layers.
- Identify the design problem.
- Recognize the pattern family.
- Learn the individual patterns one at a time.
- Practice recognizing them in real systems.
This approach is much more natural and much easier to remember.
Interview Perspective
Interviewers rarely ask candidates to list all 23 GoF patterns.
Instead, they present a design problem.
For example:
- "Object creation depends on runtime configuration."
- "Third-party APIs have incompatible interfaces."
- "Business algorithms change frequently."
Strong candidates first identify the category of problem.
Only then do they discuss a specific pattern.
This shows that they understand why the pattern exists—not just what it's called.
Key Insight
The GoF catalog isn't a collection of random solutions.
It's a map of recurring software design problems.
Each family addresses a different aspect of object-oriented design:
- Creating objects.
- Organizing objects.
- Managing object behavior.
Once you understand this roadmap, learning individual patterns becomes much more intuitive.
In This Article, You Learned
- Why the 23 GoF Design Patterns are grouped into three families.
- What kinds of problems each family addresses.
- A simple mental model for recognizing which family to explore.
- Why experienced engineers classify problems before choosing patterns.
One-Line Takeaway
Don't start by asking which Design Pattern to use—start by identifying whether your problem is about creating objects, organizing them, or managing their behavior.
Top comments (0)