GoF Design Patterns Reference

A comprehensive reference for the Gang of Four design patterns. This skill provides language-agnostic guidance with pseudocode examples that can be translated to any programming language.

When This Skill Activates

This skill automatically activates when you:

• Ask about or need to implement a design pattern

• Need to choose between patterns for a design problem

• Are refactoring code and considering structural improvements

• Discuss architecture, decoupling, or extensibility

• Mention specific patterns: factory, singleton, observer, decorator, etc.

Quick Pattern Reference

Creational Patterns (Object Creation)

Pattern Intent Use When

Abstract Factory Create families of related objects Need platform/theme independence

Builder Construct complex objects step-by-step Object has many optional parts

Factory Method Let subclasses decide which class to instantiate Don't know concrete types ahead of time

Prototype Clone existing objects Object creation is expensive

Singleton Ensure single instance Need exactly one shared instance

Structural Patterns (Composition)

Pattern Intent Use When

Adapter Convert interface to expected interface Integrating incompatible interfaces

Bridge Separate abstraction from implementation Need to vary both independently

Composite Treat individual and groups uniformly Have tree structures

Decorator Add responsibilities dynamically Need flexible extension

Facade Simplified interface to subsystem Complex subsystem needs simple API

Flyweight Share common state efficiently Many similar objects needed

Proxy Control access to object Need lazy loading, access control, logging

Behavioral Patterns (Communication)

Pattern Intent Use When

Chain of Responsibility Pass request along handler chain Multiple handlers, unknown which handles

Command Encapsulate request as object Need undo, queue, or log operations

Interpreter Define grammar and interpret sentences Have a simple language to parse

Iterator Sequential access without exposing internals Need to traverse collections

Mediator Centralize complex communications Many objects communicate in complex ways

Memento Capture and restore object state Need undo/snapshot functionality

Observer Notify dependents of state changes One-to-many dependency

State Alter behavior when state changes Object behavior depends on state

Strategy Encapsulate interchangeable algorithms Need to swap algorithms at runtime

Template Method Define skeleton, let subclasses fill in Algorithm structure fixed, steps vary

Visitor Add operations without changing classes Need to add many operations to stable structure

Decision Guide

See Pattern Selection Guide for help choosing the right pattern.

How to Use This Reference

• Choosing a pattern: Start with the decision guide or tables above

• Learning a pattern: Read the full documentation with examples

• Quick reminder: Use the tables above for at-a-glance reference

• Implementation: Follow the pseudocode, adapt to your language

Language Translation Notes

The pseudocode in this reference uses these conventions:

• class for type definitions

• function for methods/functions

• -> for method calls on objects

• // for comments

• Type hints shown as name: Type

Translate to your language:

• PHP: class , function , -> , // , type hints in docblocks or PHP 8+

• JavaScript/TypeScript: class , function /arrow, . , // , TS types

• Python: class , def , . , # , type hints

• Java/C#: Direct mapping with new , generics

Based on concepts from "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides (Gang of Four), 1994.