Design Patterns
Design Patterns are reusable solutions to common problems in software design - named, well-documented templates that developers can apply to recurring structural challenges rather than reinventing each time. The classic catalog comes from the 1994 “Gang of Four” book; the term has since broadened to cover UX patterns, interaction patterns, and architectural patterns.
The original 23 patterns (Singleton, Factory, Observer, Strategy, and the rest) are programming-specific. The broader concept - recognising and naming recurring solutions - applies across software, UX, and product design.
Why patterns matter
Three reasons:
Shared vocabulary. “Use the Observer pattern here” communicates an entire structural decision in two words. Without patterns, the same idea takes a paragraph and gets misunderstood half the time.
Pre-validated solutions. Patterns exist because someone solved the problem badly first, then better, then well enough to document. Adopting the pattern skips the bad and better stages.
Onboarding speed. A new developer reading code structured around named patterns gets up to speed faster than one reading entirely bespoke architecture.
Where pattern thinking goes wrong
Pattern-hunting. Junior developers learn the catalog and start applying patterns in search of problems. A simple two-class relationship becomes a Visitor pattern. The pattern adds complexity the actual problem didn’t justify.
Pattern dogma. “We always use the Repository pattern for data access” - even when the codebase has 50 simple read operations and the abstraction is pure overhead.
Confusing pattern with implementation. A pattern is a structural idea. Two implementations of the same pattern can look very different. Insisting on one specific code shape misses the point.
An example
A solo developer building a niche affiliate site initially structured the codebase around four design patterns absorbed from a textbook - Repository, Factory, Strategy, and Observer. The site had about 200 lines of business logic doing roughly: read product data, compare on price, render comparison tables.
The patterns produced about 1,400 lines of code where 350 would have done the work. New features took twice as long because each had to navigate multiple layers of abstraction. Six months in, they refactored: deleted the Repository (replaced with three SQL queries), the Factory (replaced with two function calls), and the Strategy (replaced with an if-statement). Code dropped to 380 lines, test count halved, new feature velocity tripled.
The patterns weren’t wrong as concepts. They were wrong for a 200-line codebase. Patterns earn their complexity at scale - applied prematurely, they’re pure cost.
Related terms
- CSS - a domain with its own emerging patterns (BEM, atomic, utility-first)
- Content Modeling - an analogous pattern-thinking discipline for content
- Agile - a methodology that pairs naturally with pattern-aware design
- Algorithm - the lower-level abstraction patterns frequently encapsulate
- Accessibility Terms - a domain with its own accepted UX patterns for inclusive design