The Three Families of Patterns

In one sentence: Every classic pattern answers one of three questions — how objects get made (creational), how objects fit together (structural), or how objects talk to each other (behavioral).

Note: The GoF book actually organizes its catalog along two dimensions: purpose (the three families below) and scope — whether the pattern fixes relationships at compile time through inheritance (class patterns like Factory Method and Template Method) or keeps them changeable at runtime through object composition (almost everything else). The book's recurring advice: favor composition, which is why most patterns are object patterns. The original catalog has 23 patterns; this guide covers 22 — we omit Interpreter (building a grammar's class hierarchy to evaluate sentences in a mini-language), which is rarely used outside compiler-adjacent work.

Why the grouping matters

You'll rarely think "I need the Bridge pattern." You'll think "this class hierarchy is exploding." Knowing the three families tells you which shelf to search when you have a problem:

Creational patterns — making objects

Construction is where coupling starts: every new ConcreteThing() welds your code to one specific class. Creational patterns move that decision somewhere you control.

• Singleton — exactly one instance, globally reachable.
• Factory Method — subclasses decide which concrete object to create.
• Abstract Factory — create whole families of matching objects.
• Builder — assemble complex objects step by step.
• Prototype — clone existing objects instead of constructing from scratch.

Structural patterns — composing objects

Once objects exist, they must be wired into larger structures — without the structure becoming concrete. Structural patterns are mostly clever ways of wrapping and composing.

• Adapter — translate one interface into another.
• Bridge — split one exploding hierarchy into two independent ones.
• Composite — treat one object and a tree of objects identically.
• Decorator — add behavior by wrapping, stackable at runtime.
• Facade — one simple front door to a complex subsystem.
• Flyweight — share repeated heavy data across many objects.
• Proxy — a stand-in that controls access to the real object.

Behavioral patterns — objects talking

The biggest family, because communication is where designs rot: objects that know too much about each other can't be changed independently. Behavioral patterns cut those wires.

• Chain of Responsibility — pass a request along until someone handles it.
• Command — turn an action into an object (queue it, log it, undo it).
• Iterator — walk a collection without knowing its layout.
• Mediator — route communication through a central hub.
• Memento — snapshot state for later restore, without breaking encapsulation.
• Observer — notify subscribers automatically on change.
• State — behavior that changes with internal state, without giant switches.
• Strategy — swap algorithms at runtime like cartridges.
• Template Method — fixed algorithm skeleton, customizable steps.
• Visitor — add operations to a class family without touching it.

Where to start

If you're new to patterns, this order gives the fastest payoff:

1. Strategy — the simplest and most useful; teaches "program to an interface."
2. Observer — the heart of every event system and UI framework.
3. Factory Method — the standard cure for new scattered everywhere.
4. Decorator — the "aha!" pattern that makes composition click.

Tip: Don't binge all 22 in one sitting. Read three or four, then go find them in code you already know — the STL, Qt, your own projects. Recognition is what makes patterns stick.