Design Pattern Catalog¶
Reference catalog — instantiates Archetype Pattern Indexing
Indexes proven solution structures by their forces and structure, with known uses and the neighboring patterns each is easily confused with.
A Design Pattern Catalog indexes recurring solutions worth reaching for — each entry a proven structure defined by the forces it resolves and the arrangement of parts that resolves them. Its defining move is reuse by structural signature: you locate a pattern not by a remembered name but by matching the tensions in your problem to a pattern's stated forces, then adopt the arrangement it prescribes. Every entry carries known uses that prove it works in the wild and an explicit map of the neighboring patterns it is easily confused with, so the catalog teaches not just what to build but which of several look-alike solutions actually fits. It indexes structures to adopt, and it earns its keep by making that adoption discriminating rather than cargo-cult.
Example¶
A platform team maintains a design pattern catalog for their service architecture, in the tradition of the "Gang of Four."[1] An engineer facing a problem — a subsystem that must talk to several incompatible payment providers whose interfaces keep changing — does not search for a name; she searches by forces: "must decouple a client from concrete provider APIs; providers vary; want to swap them without touching callers." The catalog returns the Adapter pattern, whose signature (wrap each provider behind a common interface the client depends on) matches those forces, with three known uses inside the company as proof. Critically, its neighbor-distinction section warns that Facade looks similar but solves a different force (simplifying a complex subsystem, not reconciling incompatible interfaces), and Strategy varies behavior rather than interface. She picks Adapter deliberately, having ruled out the two patterns she would otherwise have conflated it with — the catalog's whole value in one lookup.
How it works¶
Each entry is a structure recorded for adoption. Its core is a signature: the recurring forces and constraints the pattern resolves, plus the arrangement of collaborating parts that resolves them — this is what a problem is matched against. Around the signature sit known uses, real instances that show the pattern transfers and mark the contexts where it has paid off, and a neighbor map naming the adjacent patterns most often confused with it and the force that separates them. Retrieval is force-first: you enter with the tensions in your problem and the catalog surfaces candidate structures, then the neighbor distinctions narrow the field to the one that fits. What distinguishes it from a loose collection is that entries are indexed on structure, not name, and every entry knows its nearest relatives.
Tuning parameters¶
- Signature abstraction level — how general each pattern's forces are stated. High abstraction transfers across more domains but overmatches easily; concrete forces recognize precisely but travel less far.
- Known-uses bar — how much field evidence an entry needs before admission. A high bar keeps the catalog trustworthy; a low one grows coverage but admits unproven patterns.
- Neighbor-map density — how many confusable relatives each entry names. Denser maps prevent conflation but are costly to author and can overwhelm a first-time reader.
- Consequence detail — how fully each entry states the trade-offs of adopting it, so reuse stays deliberate rather than reflexive.
When it helps, and when it misleads¶
Its strength is discriminating reuse: a well-built catalog lets someone match a problem's forces to a proven structure and rule out the two or three patterns they would otherwise have confused it with, which is where most misapplied patterns come from.
Its failure mode is pattern overmatching — reaching for a familiar structure because the surface of the problem resembles a known use, without checking that the underlying forces match, so a system sprouts abstractions it does not need. The classic misuse is treating the catalog as a checklist to apply exhaustively rather than a menu to select from. The guarding discipline is to make retrieval go through the forces and the neighbor distinctions, not the names — to require that a chosen pattern's stated forces are actually present, and that its nearest neighbors have been considered and rejected, before it is adopted.
How it implements the components¶
pattern_signature— each entry's forces, constraints, and part-arrangement are the structural definition a problem is matched against; this is the catalog's primary retrieval key.example_set— the known-uses section supplies real instances that prove the pattern transfers and mark the contexts where it fits.neighbor_distinction— every entry names the adjacent patterns it is confused with and the force that separates them, so selection is discriminating rather than reflexive.
It carries no counterexample_set of legitimate look-alikes, prescribes no remediation as response_guidance, and attaches no confidence_label — those warning-and-fix roles belong to its nearest twin, Anti-Pattern Catalog: this catalog indexes structures to adopt, the anti-pattern catalog indexes structures to escape.
Related¶
- Instantiates: Archetype Pattern Indexing — it supplies the positive-reuse side of the index, retrievable by structural forces rather than by name.
- Consumes: Pattern Card Template gives each entry its fixed slots.
- Sibling mechanisms: Anti-Pattern Catalog · Case Library · Diagnostic Atlas · System Archetype Index · Solution Archetype Archive · Pattern Card Template · Tagging Schema · Pattern Library — a browsable vocabulary of approved exemplars for coherent recombination, where this catalog is organized for structural retrieval (signature and neighbors) instead.
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Design Pattern Catalog operates as a non-executable information artifact that externalizes static or prospective structure because it indexes proven solution structures by their forces and structure, with known uses and the neighboring patterns each is easily confused with.
Independent corroboration: The frozen evidence defines Design Pattern Catalog as 'Indexes proven solution structures by their forces and structure, with known uses and the neighboring patterns each is easily confused with', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Software engineering cohered modern design-pattern catalogs through the Gang of Four's intent, structure, known-use, and related-pattern format.
Related originating lineages:
- Architecture & Urban Planning — Christopher Alexander's pattern language supplied the originating context-forces-solution form.
Review resolution: Software engineering cohered modern design-pattern catalogs through the Gang of Four's intent, structure, known-use, and related-pattern format. The retained alternate lineages materially shaped the mechanism's form.
Attribution caveat: The catalog's modern recognizable method is software-derived, with explicit architectural ancestry.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson & Vlissides, 1994) — the "Gang of Four" — set the modern template for a design pattern catalog: each entry states Intent and Structure (its signature), Known Uses (its examples), and Related Patterns (its neighbor distinctions). registry ↩