Programming Fundamentals
Design Patterns
Battle-tested solutions to recurring design problems — Factory, Strategy, Observer, Singleton, Adapter and friends. They give teams a shared vocabulary and steer you toward flexible structure. Applied blindly they add needless ceremony, so reach for one only when the problem it solves has actually shown up in your code.
Purpose
Design patterns are named, battle-tested solutions to recurring design problems — Factory for controlled creation, Strategy for swappable algorithms, Observer for event notification, Adapter for mismatched interfaces. They exist to give teams a shared vocabulary: 'use a Strategy here' communicates a whole design in three words.
When to Use It
Reach for one when its problem has actually appeared: many interchangeable behaviours (Strategy), one-to-many updates (Observer), complex object construction (Builder/Factory), or wrapping a third-party API behind your own interface (Adapter). Frameworks are full of them — recognising the pattern makes the framework legible.
Trade-offs
Applied speculatively they add layers of indirection that solve nothing — the classic 'patternitis'. A Singleton in particular is often a global variable in disguise, hurting testability. The value is in matching a real problem to a known shape, not in decorating code with pattern names.
Implementation
Learn the intent of each pattern rather than memorising UML; most reduce to 'program against an interface and vary the implementation'. Introduce a pattern as a refactor when duplication or rigidity emerges, and prefer the language's native features (first-class functions, modules) when they express the same idea more simply.