Patterns Are Vocabulary
Name them out loud — and in the code.
Patterns are the words two engineers use at the whiteboard so they do not have to describe a thing from first principles. The vocabulary works only if both speakers know the words, and only if the words also live in the code.
Opinion
I've sat through enough whiteboard sessions where someone said “let's use a strategy here” and meant five different things by it to know that the GoF book's original gift was not the patterns; it was the words.1Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994). The lasting contribution is the names: Strategy, Singleton, Visitor, Factory. Without the words, the patterns would have been re-invented in every team rather than reused. Strategy. Factory. Repository. Visitor. The vocabulary is the value. A Factory called OrderCreator is a Factory the next reader has to discover by reading; a class called OrderFactory announces itself in ls.
The naming rule is small and it bites. A class that produces instances is a Factory, not a Creator and not a Provider and not a Maker; those words mean different things in the catalogue and conflating them makes the catalogue useless.2Design Patterns reference (refactoring.guru/design-patterns). Each entry names the pattern, its intent, its structure, and crucially the conventional class-name suffix or prefix that flags an instance of the pattern in code review. A class that observes is an Observer, not a Listener unless the framework demands it. A class that adapts is an Adapter; a class that simplifies is a Facade; a class that controls access is a Proxy. Pick the one whose semantics match. This is F2 Intention-Revealing Names applied at the pattern layer.
The corollary nobody likes: read the catalogue once and stop. Strategy was written better in 1994; Repository was written better by Fowler in 2002; POODR explained the inheritance trap better than I will.3Practical Object-Oriented Design in Ruby (POODR), 2nd ed. (2018). The deepest single treatment of when not to reach for a pattern; Chapter 6 on inheritance is the canonical statement that a pattern misnamed is a pattern misused. Cite, do not paraphrase: the catalogue is somebody else's lifetime of work and rewriting it would be the wrong abstraction (see PT2 Don't Force the Pattern). The job here is to make the vocabulary land in the code.
Copy a note and link
Grab this short comment and drop it into a PR comment or an LLM chat to prompt the right change.
If a class implements a known pattern, name it for that pattern. A Factory is `*Factory`. A Repository is `*Repository`. The pattern's name belongs in the identifier, not just the conversation. If you can't name the pattern, you may not have one — don't manufacture one. /tenet/patterns-are-vocabulary/PT1
AI eyes only
Rule: name patterns out loud, in code. If it acts like a Factory, call it a Factory.
Reject: a textbook Repository named OrderStore. Reject: a textbook Adapter named Wrapper. Reject: claiming a pattern when only the shape coincides.
Generate: when emitting a class or module that fits a textbook pattern, name it after the pattern (UserRepository, PaymentAdapter). When two functions only happen to share shape, do not invoke the pattern.
Diagnostic: state the pattern out loud and recite its Intent. If the recited Intent matches what the code does, the name is right. If it does not, do not invoke the pattern.
Why?
- Two engineers at a whiteboard say “Strategy” and mean the same thing. The GoF catalogue's lasting contribution is the words; PT1 keeps them earning their keep in the code.
lsbecomes a glossary.order-factory.ts,order-repository.ts,order-observer.tstell the next reader where the design is before they open a file.- Pairs with F2 Intention-Revealing Names: F2 says the signature is the spec; PT1 says the pattern is part of the signature.
- Naming is the one part of the patterns layer the linter reaches.
@typescript-eslint/naming-convention, Ruff'sN801, PMD'sClassNamingConventions— the suffix rule is enforceable; the rest of the pattern isn't. - Review conversations stop being archaeology. “Where's the Factory?” is a one-grep question; review time goes to design, not to file-tree navigation.
- Agents have read every catalogue and know the names. The CLAUDE.md instruction “if it acts like a Factory, call it a Factory” closes the gap between the agent's knowledge and the codebase's nomenclature.
- Read the catalogue once and stop. GoF, refactoring.guru, Fowler, Metz did the work; the team's job is to use the words, not rewrite them. The pillar is a curator, not an author.
Origins
The pattern catalogue arrived in 1994 with Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides's Design Patterns: Elements of Reusable Object-Oriented Software — the “Gang of Four” book.1Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994). The lasting contribution is the names: Strategy, Singleton, Visitor, Factory. Without the words, the patterns would have been re-invented in every team rather than reused. The book's lasting contribution wasn't the twenty-three patterns themselves, most of which had been observed in working systems for years, but the six-section template (Intent / Motivation / Applicability / Structure / Participants / Consequences) and, crucially, the names. Strategy. Singleton. Visitor. Factory Method. Without the names, two engineers describing the same thing had to start from scratch every time.
Christopher Alexander's A Pattern Language (1977) is the architectural forebear, and the GoF authors cite it directly: a pattern names a recurring problem and a vocabulary for its solution.7A Pattern Language: Towns, Buildings, Construction (Oxford UP, 1977). The architectural-design book the GoF authors cite directly. A pattern names a recurring problem and a vocabulary for its solution. Kent Beck's Smalltalk Best Practice Patterns (1996) carried the naming-as-design discipline forward into the OO mainstream, and Sandi Metz's POODR (2009; 2nd ed. 2018) is the most thorough single treatment of when not to reach for a pattern — and what the right names look like when you do.3Practical Object-Oriented Design in Ruby (POODR), 2nd ed. (2018). The deepest single treatment of when not to reach for a pattern; Chapter 6 on inheritance is the canonical statement that a pattern misnamed is a pattern misused.
Martin Fowler's Patterns of Enterprise Application Architecture (2002) extended the catalogue upward to the architectural layer — Repository, Unit of Work, Data Mapper, Active Record — and made those names load-bearing in every web framework written since.8Patterns of Enterprise Application Architecture (Addison-Wesley, 2002). Repository, Unit of Work, Data Mapper, Active Record — extends the GoF vocabulary to the architectural layer; every web framework written since uses these names. The modern accessible reference is refactoring.guru: free, illustrated, the entry point most engineers under thirty-five reach for first. Refactoring Guru is what teams cite in code review now; the GoF book is what the citations point at.
The naming-rule half of PT1 is older still. Brian Kernighan and P. J. Plauger's The Elements of Programming Style (1974) puts it in five words: “say what you mean, simply.”9The Elements of Programming Style (McGraw-Hill, 1974; 2nd ed. 1978). “Say what you mean, simply.” Half a century before Clean Code, the discipline of letting the identifier carry the design was in print. Decades before Clean Code, the discipline of letting the identifier carry the design was in print. PT1 is that rule plus the catalogue: the name says what it is, and the name has to match the canonical word the catalogue already gave us.
Quotes
Each design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems.
Design patterns are descriptions of best practices, not building blocks; they are about how we build things, not what we build.
The road from grasping a pattern to misapplying it is short. The named pattern is a tool; the named misuse is just a tool used badly.
The intent of a piece of code should be communicated by its name; if the name does not carry the intent, the name is wrong, not the comment.
Evidence
Twenty external sources, ranked by author authority. The first five are the canon; expand to see the rest, including the qualifiers and the named opposers. Each links out to its primary source.
- 01The book that gave the industry the words. The 23 patterns are a vocabulary; the lasting contribution is the names — Strategy, Singleton, Visitor, Factory — that two engineers can use without describing the thing from first principles.
- 02Design PatternsSupportsThe free, illustrated, modern walkthrough of the GoF patterns plus Fowler's refactorings. The reference most engineers under thirty-five reach for first; supports the naming-as-vocabulary rule with worked examples in ten languages.
- 03Extends the GoF vocabulary upward to the architectural layer. Repository, Unit of Work, Data Mapper, Active Record — every web framework written since uses these names. Confirms vocabulary is the lasting contribution.
- 04Smalltalk Best Practice PatternsSupportsPre-GoF treatment of naming-as-design. Treats names as primary; the word in the identifier carries the design intent. The closest predecessor to PT1's naming rule.
- 05The deepest single treatment of when not to reach for a pattern. Naming is part of the discipline — but Metz's rule is to name only when the pattern is real, never to manufacture one for the sake of vocabulary.
Sixteen sources, three stances. The supporters are the canon: Gamma et al. (GoF), Refactoring Guru, Fowler's PoEAA, Beck's Smalltalk Best Practice Patterns, and Metz's POODR. The qualifiers further down carry the “name the right thing” nuance: first-class functions and dynamic dispatch make 16 of 23 patterns invisible, and the vocabulary still applies to what remains. The opposers are the ones the reply has to address: when the pattern is just a function, naming it as a pattern is ceremony.
Examples
// Before: the class is a Factory, but ls -la cannot tell.export class HedgehogMaker { make(name: string, prickleCount: number): Hedgehog { return new Hedgehog(name, prickleCount); }}
// After: the pattern name lives in the type and the file.export interface Factory<T> { create(...args: readonly unknown[]): T; }export class HedgehogFactory implements Factory<Hedgehog> { create(name: string, prickleCount: number): Hedgehog { return new Hedgehog(name, prickleCount); }}
AI rules
.cursor/rules/pt1-patterns-are-vocabulary.mdc---
description: Prickles PT1 — Patterns Are Vocabulary
globs: "**/*.{ts,tsx,js,jsx,py,java,php}"
alwaysApply: false
---
## Prickles PT1 — Patterns Are Vocabulary
If a class implements a known pattern, name the pattern in the identifier. A Factory is `*Factory`. A Repository is `*Repository`. An Adapter is `*Adapter`. An Observer is `*Observer`. An abstract base is `Abstract*` or marked `abstract` in the language.
Read GoF, Refactoring Guru, or Fowler's PoEAA once so the names mean the same thing across team and code. Do not paraphrase the catalogue; cite it.
Refuse to introduce a pattern unless the pattern is unmistakable from the requirement. When the pattern is real, name it; when it isn't, don't manufacture one.
If you discover the code already implements a pattern after the fact, rename it to the canonical word. A Repository called `OrderStore` is a missed signal; rename it `OrderRepository`.Repo layout, CI, and ESLint wiring for these paths live on /implementation — not repeated on every tenet.
Counter-argument
The strongest steelman is Peter Norvig's.4“Design Patterns in Dynamic Languages” (1996). Sixteen of the twenty-three GoF patterns become invisible or one-liners in a language with first-class functions and dynamic dispatch. The reply: the vocabulary outlives the class hierarchy. In a language with first-class functions and dynamic dispatch, sixteen of the twenty-three GoF patterns become invisible or one-liners: Strategy is a function passed as an argument; Iterator is a generator; Command is a closure. Insisting on the GoF vocabulary in those cases is performing patterns rather than using them, and the “call a Factory a Factory” rule risks pushing teams toward Java-shaped class hierarchies in languages that explicitly do not need them. Steve Yegge sharpens the same point: the kingdom of nouns is a cage, and pattern-as-class-name is one of its bars.5“Execution in the Kingdom of Nouns” (2006). The cultural critique of treating every concept as a noun-class; pattern-as-class-name is one of the bars. PT1's reply is to make the rule descriptive, not coercive.
Counter-argument retort
Norvig is right about dynamic-language patterns and the rule still holds. The vocabulary isn't the class hierarchy; it's the word. A higher-order function that produces an instance is still a Factory. Naming the file order-factory.ts when the export is a function called createOrder tells the reviewer this is the place new orders come from — the same signal a class would carry, without the ceremony Norvig objects to.4“Design Patterns in Dynamic Languages” (1996). Sixteen of the twenty-three GoF patterns become invisible or one-liners in a language with first-class functions and dynamic dispatch. The reply: the vocabulary outlives the class hierarchy.
Yegge's “kingdom of nouns” argument5“Execution in the Kingdom of Nouns” (2006). The cultural critique of treating every concept as a noun-class; pattern-as-class-name is one of the bars. PT1's reply is to make the rule descriptive, not coercive. is the harder one, and the reply is to treat the vocabulary as descriptive, not coercive. PT1 doesn't say “turn every function into a noun-class.” It says “if you've already got a Repository, call it one.” A team writing functional TypeScript that has zero classes still has Repositories — they're modules withfind / save / delete exports talking to a store. Naming the module order-repository.ts earns its keep the same way the class name would. The vocabulary is the constraint that survives the language change.
The genuine residue is the over-naming risk — calling a function a Strategy because two callers exist. That isn't solved by PT1; it's solved by PT2 Don't Force the Pattern. The PT1 rule says: when the pattern is real, name it. The PT2 rule says: don't manufacture patterns from coincidence. Both are needed; neither is sufficient on its own. The reviewer's question becomes “is this actually a Strategy, and if so why isn't it called one?” — one question, two tenets behind it.
The lint exception is real and small. ESLint's @typescript-eslint/naming-convention, Ruff's N801, PMD's ClassNamingConventions — all can enforce a suffix on classes that implement a known interface or extend a base class.6@typescript-eslint/naming-convention rule. The lint hook that makes the suffix / prefix rule enforceable. Ruff's N801 and PMD's ClassNamingConventions are the Python and Java equivalents — the same idea, three ecosystems. That is the one foothold linters have inside the patterns layer; everything else — pattern misuse, anti-pattern detection, “you should have used Strategy here” — is unreachable to static analysis. TA1 Linter as Law names the boundary; PT1 is the one place the tooling reaches across it.
Notes
- [1]Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides — Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994). The lasting contribution is the names: Strategy, Singleton, Visitor, Factory. Without the words, the patterns would have been re-invented in every team rather than reused.
- [2]Refactoring Guru — Design Patterns reference (refactoring.guru/design-patterns). Each entry names the pattern, its intent, its structure, and crucially the conventional class-name suffix or prefix that flags an instance of the pattern in code review.
- [3]Sandi Metz — Practical Object-Oriented Design in Ruby (POODR), 2nd ed. (2018). The deepest single treatment of when not to reach for a pattern; Chapter 6 on inheritance is the canonical statement that a pattern misnamed is a pattern misused.