What is a design pattern, actually?

Before Strategy, Observer, Factory, and Decorator make sense individually, the actual idea underneath all of them — a named, reusable solution to a recurring design problem, not a rule to follow blindly.

Beginner

3 min read

Not a language feature — a named solution to a recurring problem

A design pattern is a general, reusable solution to a problem that comes up repeatedly in object-oriented design — not a specific piece of code you copy-paste, and not a feature built into Python or any other language. It's closer to a well-known recipe: a description of the problem's shape, and a proven way to structure code to solve it, that programmers can recognize and communicate about using a shared name, without re-explaining the whole idea from scratch every time.

Why patterns have names at all

"I built a system where objects can subscribe to be notified when something changes"

vs.

"I used Observer"

Both sentences describe the same idea, but the second one is instantly recognizable to anyone who already knows the pattern — a shared vocabulary that lets developers communicate a whole design shape in one word, the same way "binary search" instantly conveys an entire algorithm without re-explaining it. This is the real value patterns provide: not the code itself (which varies every time), but a name for a recurring shape of problem-and-solution, making design discussions dramatically more efficient.

Patterns describe a shape, not exact code

Two completely different codebases can both "use the Strategy pattern" while having entirely different class names, different numbers of strategies, and different languages — what makes them both Strategy is the underlying shape: a family of interchangeable algorithms, selected at runtime through a shared interface, replacing a branching conditional. A pattern is a template for a solution's structure, adapted to fit the specific problem at hand — never copied verbatim.

Where the well-known patterns actually came from

Most of the patterns covered in this domain — Strategy, Observer, Factory, Decorator, and others — trace back to a highly influential 1994 book, Design Patterns: Elements of Reusable Object-Oriented Software, written by four authors often referred to collectively as "the Gang of Four" (GoF). The book cataloged patterns that experienced object-oriented developers had already been independently reinventing across many different projects — the book's real contribution was naming and documenting them clearly, not inventing them from nothing.

The real danger: applying a pattern where it doesn't fit

class Logger:
    def log(self, message):
        print(message)

A single, simple Logger class doesn't need to become a Factory-built, Strategy-configurable, Observer-notified system — that would be solving a problem this code doesn't actually have, adding indirection and complexity with no real benefit. This is a common, real mistake, especially once someone has just learned a pattern: reaching for it everywhere, rather than only where the actual problem it solves is genuinely present. Every individual pattern lesson in this domain includes a "concrete signal" section for exactly this reason — a specific, recognizable code shape that indicates the pattern actually fits, rather than "I know this pattern, so I'll use it here."

How to actually learn patterns well

The productive order is: encounter a real design problem first (a conditional that keeps growing, a class that needs to notify others of changes it doesn't control), then recognize which pattern's shape matches it — not memorize a list of patterns and look for places to insert them. Patterns are a vocabulary for problems you'll run into naturally as you build real things, not a checklist to work through on every project.