The Gang of Four book files its twenty-three patterns under Creational / Structural / Behavioral. That taxonomy is useful for looking something up and terrible for learning, for one reason: the patterns that are easiest to confuse sit in different chapters. Strategy and Bridge draw the same class diagram. So do Strategy and State. Learn them weeks apart and “so what’s the difference?” never gets resolved.

So this series is ordered by which patterns look alike, and each module ends by naming what separates them. Because what distinguishes two patterns is never the structure – it is the intent.

Code is Kotlin. Every pattern is tagged with what the language did to it: replaced (a language feature does the job), reshaped (there is an idiomatic Kotlin form worth knowing), or as-is (nothing in the language helps – write it the way GoF describes).

The map

M0FoundationsSession 1
FoundationsWhat to look at when you look at a pattern – and how to tell when not to reach for one at all.
M1Swapping AlgorithmsSession 2-3
StrategyEncapsulate a family of algorithms as objects and swap them at runtime; the client picks.replaced
Template MethodFix the skeleton of an algorithm and let subclasses supply the varying steps.replaced
StateLet an object change its behavior wholesale as its internal state changes; the object owns the transitions.reshaped
M2Separating Object CreationSession 4-5
Factory MethodDefer the choice of which concrete class to instantiate to a subclass.reshaped
Abstract FactoryCreate whole families of related objects that must be used together, without naming their concrete classes.as-is
BuilderSeparate the construction of a complex object from its representation.replaced
PrototypeCreate new objects by cloning an existing instance.replaced
SingletonForce a class to have exactly one instance and give it a global access point.replaced
M3Wrappers: The Four SiblingsSession 6-7
AdapterChange an interface so two otherwise incompatible things can work together.replaced
DecoratorKeep the interface and add responsibilities, stackable at runtime.replaced
ProxyKeep the interface and control access – lazy loading, caching, permissions, remoting.replaced
FacadePut one simple interface in front of a complicated subsystem.as-is
M4Trees and RecursionSession 8-9
CompositeTreat individual objects and compositions of objects uniformly.reshaped
IteratorWalk the elements of a collection without exposing how it is stored.replaced
VisitorAdd a new operation over an object structure without modifying the structure.reshaped
InterpreterRepresent a grammar as a class hierarchy and evaluate sentences written in it.reshaped
M5Communication Between ObjectsSession 10-11
ObserverNotify a set of subscribers automatically when state changes; the publisher does not know who is listening.reshaped
MediatorReplace direct references between objects with a hub that coordinates them.as-is
Chain of ResponsibilityPass a request along a chain until some handler takes it, and can stop it.reshaped
CommandTurn a request into an object so it can be queued, logged, and undone.reshaped
M6State, Resources, Two-Axis GrowthSession 12
MementoCapture and restore an object’s state without breaking encapsulation.replaced
FlyweightShare common intrinsic state across many objects to cut memory.as-is
BridgeSplit abstraction from implementation so the two can vary independently.as-is
M7IntegrationSession 13
Reading LibrariesA procedure for finding patterns in real source, applied to four libraries you already use.
Auditing Your Own CodeSmells that map to patterns, patterns that should be removed, and a one-page guide for deciding.

Before adopting any of them

Three gates, all of which must pass:

  1. Has the change actually arrived twice? No predicting. Once is a coincidence; twice is a pattern.
  2. Is there exactly one clear axis of variation? Two means consider Bridge. Unclear means it is too early.
  3. Does the code get shorter, or at least easier to follow, afterward? If there are now three more files and the flow is harder to trace, that is a failure.

See also: Confusing Pairs – the patterns whose structure is identical and whose intent is not.