Design Patterns

Ground every pattern answer in this skill's reference files, not in improvised definitions. A pattern is the answer to specific forces in a design problem: recommend one only when the user's problem shows the forces it resolves.

Workflow

For code reviews or refactoring, first read review and refactoring to trace callers, preserve contracts, and verify a concrete improvement.

1. Identify the pattern(s) in the catalog below, by name or by the forces in the user's problem. Done when every pattern the question names or implies is listed, or when no pattern's forces are present; then answer with the plain function, data structure, or language feature that solves the problem.
2. Read each identified reference at references/<pattern>.md in full. When comparing patterns, read every one compared and contrast their intent, not their structure.
3. Read the language example at examples/<pattern>/<pattern>.<ext> for the user's language. For a language without an example, use the reference's Language Notes for the idiomatic form.
4. Answer with what the pattern does, the forces that call for it, the simpler alternative and when it wins, and code adapted to the user's domain (their own code, when refactoring). Write the language's idiomatic form rather than a literal GoF class diagram: closures for Strategy in JavaScript, enums for State in Rust, sync.Once for Singleton in Go. Done when every identified pattern has all four parts.

Pattern Catalog

Creational

Patterns that abstract the instantiation process.

Structural

Patterns that compose classes and objects into larger structures.

Behavioral

Patterns that assign responsibilities and manage communication between objects.

Examples

Examples are self-contained and runnable, in Python, C, C++, Java, C#, JavaScript, Rust, Go, PHP, and Swift. Each is written in its language's idiom: C emulates objects with structs and function pointers; Rust and Go use traits, interfaces, and composition in place of inheritance.