Originally published on phpdesignpatterns.dev — part of the PHP design patterns course. View this lesson on the original site.

Design patterns, clearly defined

Welcome to PHP Design Patterns. Before we open the first pattern, let's be precise about what a pattern actually is — and what it isn't — because the word gets used to mean three different things in three different places, and that confusion is responsible for most of the bad uses of patterns in real codebases.

What is a design pattern?

A working definition

A design pattern is a named, repeatable shape of object-oriented design that solves a specific kind of recurring problem in code structure.

Three words in that definition do most of the work:

Named. Patterns give a shared vocabulary to the team. Saying "let's pull this into a Strategy" is shorter and clearer than "let's make an interface with one method, write a class per branch, and let the caller pick one."
Repeatable shape. A pattern isn't a library or a function you can composer require. It's a structure — interfaces, classes, and how they relate — that you reproduce in your own code, in your own domain, every time the problem recurs.
Specific recurring problem. Patterns answer questions like "how do I let one operation behave several different ways without a giant switch?" or "how do I add behaviour to an object without modifying it?" They don't answer "how do I make my code good."

What a pattern is not

It helps just as much to be clear on what patterns aren't:

Not a goal. "Use more patterns" is never a sensible PR comment. The goal is code that's kind to its readers and easy to change. Patterns are one tool among many for getting there.
Not a library. You won't use SymfonyStrategyComponent. Patterns describe how you arrange your own classes.
Not a substitute for thinking. Two of the patterns in this course (Singleton, parts of Visitor) are routinely overused. Reaching for a pattern because it has a famous name, rather than because the code is hurting, is how you end up with a 200-class enterprise codebase doing the work of a 20-class one.
Not language-specific in spirit, but very language-specific in shape. Strategy in PHP 8 looks different from Strategy in 1995 Java. Modern PHP — readonly classes, enums, first-class callables, match — changes which patterns are still essential and which have shrunk to a one-liner. We'll flag that throughout the course.

Why we still teach them

Given all those caveats, why bother with patterns at all? Because the problems patterns solve don't go away. Variation, growth, coupling, and the need to add behaviour without rewriting old behaviour — these are the daily realities of any codebase that lives longer than a sprint. Patterns give you:

A vocabulary for naming the shapes you and your colleagues are already drawing on whiteboards.
A library of reference solutions so you don't have to invent the same wheel each time.
A reading skill. Once you know the patterns, you'll spot them in framework source code (Laravel, Symfony, Doctrine) and understand why the framework is structured that way.
A discipline of restraint. Knowing the pattern means knowing when not to apply it — and that's often the more valuable half.

How this course is organised

The course covers the full pattern catalogue — the original Gang of Four set plus the patterns that became standard in modern application code (Repository, Pipeline / Middleware, Specification, Null Object). Each chapter follows the same arc:

A concrete piece of PHP code that's hurting.
The pattern that fixes it.
The contract that makes the pattern work.
The variants you'll see in real codebases.
Trade-offs and overkill cases.
A guided refactor exercise.
A short quiz.

This first chapter is the only one that doesn't follow that shape. Its job is to give you the map: what families of patterns exist, when each family tends to show up, and how to read the rest of the course. From chapter 3 (Strategy) onwards, every chapter is a pattern.

From PHP design patterns — Introduction to design patterns