What are the three categories of GoF patterns?

Creational patterns abstract how objects are made (Factory, Builder, Singleton, Prototype, Abstract Factory). Structural patterns compose objects into larger structures (Adapter, Decorator, Facade, Proxy, Composite, Bridge, Flyweight). Behavioral patterns assign responsibilities and manage communication between objects (Observer, Strategy, Command, State, and seven more), for 23 patterns in total.

What is the difference between Strategy and State?

Both swap behavior behind an interface, but their intent differs. Strategy lets a client choose an interchangeable algorithm explicitly, such as a sorting or pricing strategy. State lets an object change its own behavior as its internal state transitions, so it appears to change class — the object, not the client, drives the switch.

When should I reach for a design pattern?

Only when the problem the pattern solves is actually present. Patterns are shared vocabulary for recurring designs, not goals in themselves. Forcing a pattern onto simple code adds indirection without benefit; the SOLID and KISS principles warn against this. Recognize the problem first, then name the pattern.

Is Singleton an anti-pattern?

It is the most criticized GoF pattern because it introduces global state, hides dependencies, and complicates testing. It is fine for genuinely single shared resources like a configuration object, but prefer dependency injection so the single instance is passed in rather than fetched from a global accessor.

What is the difference between Adapter, Facade and Proxy?

All three wrap another object but for different reasons. An Adapter converts one interface into another the client expects. A Facade gives a simple unified entry point to a complex subsystem. A Proxy provides a stand-in with the same interface to control access, add lazy loading, caching, or remote calls.

What is the GoF Design Patterns Reference?

Searchable Gang of Four design pattern reference: all 23 creational, structural and behavioral patterns with their intent and the situation each one solves, so you can pick the right pattern by problem. It runs free in your browser on Gera Tools, with nothing uploaded.

GoF Design Patterns Reference

Name: GoF Design Patterns Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

The Gang of Four book (Gamma, Helm, Johnson, Vlissides, 1994) catalogued 23 reusable solutions to recurring object-oriented design problems. Knowing them gives you a shared vocabulary and a head start on structuring code. This reference lists every pattern with its intent and the situation it addresses.

How it works

The 23 patterns split into three families:

Creational (5) — control object creation: Abstract Factory, Builder, Factory Method, Prototype, Singleton.
Structural (7) — compose objects and classes: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.
Behavioral (11) — manage algorithms and responsibilities: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

For each, read the intent (what it achieves) and the when note (the problem that justifies it). Match the problem first, then apply the pattern.

Example

You need to add logging and compression to a data stream without subclassing every stream type for every combination. That is the Decorator problem: wrap the stream in a LoggingStream, then wrap that in a CompressingStream, each adding one responsibility and forwarding the rest. The combinations multiply at runtime, not through a class explosion.

Notes

Patterns describe relationships and intent, not specific code — the same pattern looks different across languages.
Several patterns overlap by structure but differ by intent (Adapter vs Decorator vs Proxy all wrap an object).
Modern languages bake some patterns in: first-class functions make Strategy and Command lightweight, and iterators are built into most standard libraries.
Over-applying patterns is a smell of its own — see the SOLID, KISS and YAGNI principles for the counterweight.

Common confusion pairs

Adapter vs Decorator vs Proxy

All three wrap a target object, which is why they are routinely conflated:

Adapter changes the interface — it lets a client use an incompatible class by translating calls. The classic example is wrapping a legacy API so it matches a new interface the rest of the codebase expects.
Decorator keeps the same interface and adds behaviour — wrapping a Beverage in a MilkDecorator still gives you a Beverage, just with extra cost and description.
Proxy keeps the same interface and controls access — a remote proxy forwards calls across a network, a virtual proxy delays expensive construction, a protection proxy checks permissions.

Strategy vs Template Method

Both define a family of algorithms, but the inversion of control differs. Strategy injects the algorithm from outside (composition) — the client passes a sorting strategy to a Sorter that calls it. Template Method defines the skeleton in a base class and lets subclasses fill in specific steps (inheritance) — the base class calls doStep() which the subclass overrides.

Observer vs Mediator

Both handle loose coupling between objects. Observer is one-to-many: a subject notifies many subscribers when its state changes, and subscribers react independently. Mediator centralises coordination: components talk to the mediator, not to each other, which makes complex many-to-many communication manageable but concentrates logic.

Which patterns appear most in modern codebases

Despite the book’s age, most of the patterns survive in modern frameworks, often by a different name:

Pattern	Where you see it
Observer	Event emitters, reactive streams, Redux actions
Strategy	Sorting comparators, pluggable auth methods
Decorator	Express/Koa middleware, Python `@decorator`
Factory Method	ORM model creation, DI containers
Singleton	Module-level exports (used carefully)
Command	Undo stacks, job queues, CQRS write side
Iterator	`for...of`, generators, cursor pagination
Facade	Service layers hiding a complex subsystem

The anti-pattern version of each usually involves reaching for the pattern when simpler code would do — a Singleton for a stateless utility, or a full Command stack for a feature with no undo requirement. Apply the pattern when the problem it solves is genuinely present.