Patterns in the Wild
The catalog is only yours once you can spot patterns in strangers' code, learn new ones cold, and delete the ones that never earned their keep.
The idea
Eleven modules handed you thirteen patterns by making you build them. This last one is about the thing that turns them into shared knowledge: a pattern is not code, it's a named write-up of a recurring design problem, its solution, and its costs. The names do real work. "Wrap it in a decorator" transmits an entire design in four words.
The classic catalog sorts patterns into three drawers. Creational ones cover how objects get made, structural ones cover how objects compose, behavioral ones cover how objects talk and split work. You built the famous half. The other nine are rarer, but now that you know how pattern write-ups are shaped, you can pick any of them up from a single paragraph of intent. No tutorial needed.
In real codebases patterns wear no name tags. A logging library's handler chain is Chain of Responsibility, an ORM's query object is a Builder, every clone method is Prototype waving at you. Spotting them is trainable: find the seam that varies, look at who holds a reference to whom, then ask what change this structure makes cheap. Naming what you find, with evidence, is how senior engineers read an unfamiliar repo in an afternoon.
The pattern you decline is also a design decision. Indirection is paid for by every future reader, and the failure mode has a name: a Singleton for a constant, a Strategy with exactly one strategy, a Factory with one call site. Refactor to a pattern when a real force arrives, never speculatively. This module ends by making you delete patterns on purpose, because the final skill is restraint.
The bench — 3 exercises
The Pattern Hunt
File a field report on patterns you find in a real codebase already on your disk, so the book's "you'll see them everywhere" promise becomes something you can check.
- Pick a target: a repo you actually work in, or your language's standard library source.
- Read until you find at least four distinct patterns spanning at least two catalog categories.
- Write report.md with one entry per find: pattern, category, evidence as file path plus symbol, intent_here in one plain sentence, and one honest consequence it carries.
- Write intent_here in your own words about this codebase, never the textbook definition.
- Re-open each cited file and confirm the symbol is really there before you call the report done.
hint
Hunt by smell, not by name: a class that only holds another object and forwards calls is structural, a make/of returning an interface type is creational, anything with register/notify or a handle() that acts-or-passes-along is behavioral.
hint
Iterators and observers hide inside language features like for-of loops and event emitters; those count if you cite the machinery underneath.
hint
Leftover patterns count double for bragging rights: Builder and Chain of Responsibility are common in pipelines and web frameworks.
DONE WHEN
· Report has at least four entries covering at least two categories
· Every cited file exists and every cited symbol is found in it
· No pattern claimed twice on the same class
· Each intent_here reads as your sentence, not a catalog definition
The Leftovers Gauntlet
Implement three patterns you were never taught, working only from a one-paragraph intent card, to prove the catalog is now self-serve.
- Pick any three of the leftovers: Builder, Chain of Responsibility, Memento, Visitor, Flyweight, Prototype, Bridge, Mediator, Interpreter.
- For each, write the intent card yourself first in catalog register: problem, solution, consequences, under 120 words.
- Write the acceptance tests before the implementation, including a shape check, not just an input/output check.
- Build Memento over your module-5 remote and Visitor over your module-8 menu tree without editing either package.
- Run the suites and confirm the shape checks fail if you cheat the structure.
hint
The test file is the real intent card: design against it, not against a mental picture of the UML.
hint
If your Flyweight holds position or any per-instance data, it isn't one; the shared object keeps only what is identical across all users, callers pass the rest in.
hint
For Visitor, the single accept() hook is the only door you're allowed to add to the element classes.
DONE WHEN
· Three suites green, each with a structural check beyond I/O
· Module 5 and module 8 sources are unmodified (git diff is clean there)
· Mediator colleagues never import each other; Flyweight instance count stays under a small cap
The De-Pattern Kata
Take a deliberately over-built class and delete machinery until it is as simple as its actual job, with behavior byte-identical throughout.
- Write (or take from the starter) a class that returns a constant greeting via a thread-safe lazy Singleton holding a Factory selecting among Strategy objects, of which exactly one exists.
- Pin the observable behavior with a golden test and record its exact output.
- Delete whole classes and files in small steps, running the golden test between every deletion.
- Stop only when the public entry point is roughly one function returning one string.
- Write a one-sentence WHY.md naming the force that would justify re-introducing Strategy here.
hint
If you're refactoring the Singleton into a simpler Singleton, zoom out; the end state removes it entirely.
hint
The discomfort of throwing away design is the lesson: it was ceremony, not design.
hint
A real second greeting variant chosen at runtime would earn the pattern back, and that's exactly what WHY.md should say.
DONE WHEN
· Golden output identical to the starter's, byte for byte
· At most one class remains, with no getInstance, factory, or strategy indirection
· Public entry-point signature unchanged
· WHY.md exists and names a concrete re-introduction force
Go deeper (after the bench)
Read HFDP ch. 13 (Better Living with Patterns) before the hunt, since it's the field manual for it, then dip into the Leftover Patterns appendix one pattern at a time after each gauntlet bench passes, so it reads as confirmation rather than instruction. Keep Refactoring.Guru's design-patterns catalog (free) open as your reference shelf during the gauntlet, reading each entry only after your spec is green.