translating-gof-patternslisted

# Translating GoF Patterns ## Overview The classic design patterns are not obsolete in functional code; most of them are simply smaller. A pattern that needed an interface, two classes, and a registry usually becomes a function, a function type, or a choice type. The problem each pattern solves is still real; the scaffolding built to solve it in a language without first-class functions is not. Knowing the translation matters for two reasons: it stops a familiar name dragging a heavy implementation into a functional codebase, and it makes object-oriented code readable when porting it. ## When to use - About to name something `...Factory`, `...Strategy`, or `...Manager` - Porting object-oriented code to a functional style - A pattern's usual implementation feels like ceremony here - Choosing how to make one piece of behaviour vary Not for: deciding module boundaries, which is [designing-deep-modules](../designing-deep-modules/SKILL.md). ## The translation table | Pattern | Functional form | | ---------------- | ----------------------------------------- | | Strategy | A function parameter | | Command | A value describing the action | | Factory | A function returning a value | | Abstract Factory | A record of constructor functions | | Template Method | A function taking the varying steps | | Decorator | A function wrapping a function