# Why Learn Patterns

> What knowing design patterns buys a developer or coding agent: shared vocabulary, faster code reading, better refactoring targets, and knowing when to stop.

- kind: guide
- category: design-patterns
- canonical: https://aipatterns.dev/guides/why-learn-patterns
- inspired-by: https://refactoring.guru/design-patterns/why-learn-patterns

## The short answer

You will meet these patterns whether you learn them or not. Frameworks, standard libraries and existing codebases are full of them. **Learning patterns is mostly about reading code faster and deciding with fewer mistakes, not about writing more abstractions.**

## Benefits

### A shared vocabulary

"Wrap the payment client in an [Adapter](https://aipatterns.dev/design-patterns/adapter.md)" says in six words what would otherwise take a paragraph: a new class, a target interface the rest of the app already uses, and translation of calls and errors. In code review, a commit message or an agent's plan, names compress design discussion.

### Faster code reading

When you recognize a role, you can predict the rest of the structure. Spotting a class named `*Handler` with a `next` field tells you to look for a [Chain of Responsibility](https://aipatterns.dev/design-patterns/chain-of-responsibility.md) and find where the chain is assembled. Spotting `subscribe`/`unsubscribe` tells you to look for an [Observer](https://aipatterns.dev/design-patterns/observer.md) and check for listener leaks.

Common places you will see patterns without being told:

| You see | Likely pattern |
|---|---|
| Express or Koa middleware, servlet filters | [Chain of Responsibility](https://aipatterns.dev/design-patterns/chain-of-responsibility.md) |
| `addEventListener`, RxJS, Node `EventEmitter` | [Observer](https://aipatterns.dev/design-patterns/observer.md) |
| Query builders, `StringBuilder`, test data builders | [Builder](https://aipatterns.dev/design-patterns/builder.md) |
| Java I/O streams, HTTP client interceptors | [Decorator](https://aipatterns.dev/design-patterns/decorator.md) |
| ORM lazy-loaded relations, JS `Proxy` | [Proxy](https://aipatterns.dev/design-patterns/proxy.md) |
| Undo stacks in editors | [Command](https://aipatterns.dev/design-patterns/command.md) and [Memento](https://aipatterns.dev/design-patterns/memento.md) |
| Compiler AST passes | [Visitor](https://aipatterns.dev/design-patterns/visitor.md) |

### Better refactoring targets

Smells tell you something is wrong. Patterns tell you what "better" can look like. A growing type switch ([Switch Statements](https://aipatterns.dev/refactoring/smells/switch-statements.md)) has a known destination in [Strategy](https://aipatterns.dev/design-patterns/strategy.md) or [State](https://aipatterns.dev/design-patterns/state.md). Two incompatible classes doing the same job ([Alternative Classes with Different Interfaces](https://aipatterns.dev/refactoring/smells/alternative-classes-with-different-interfaces.md)) may need an [Adapter](https://aipatterns.dev/design-patterns/adapter.md). Having a destination keeps refactoring from drifting.

### Knowing when to stop

Each pattern on this site has a "Do not use it when" section. Learning a pattern properly includes learning its misfits. Developers who know only the solution side apply it everywhere. Developers who know the forces apply it where it pays.

## Why it matters more for agents

An AI coding agent generates code quickly, so the cost of over-engineering is paid by the humans who maintain the result. Patterns help an agent in specific ways:

- **Recognize existing structure before editing.** If a codebase already uses [Strategy](https://aipatterns.dev/design-patterns/strategy.md) for pricing rules, add a new strategy; don't add a new `if` inside the context.
- **Communicate intent.** A plan that says "introduce a [Facade](https://aipatterns.dev/design-patterns/facade.md) over the three reporting services" is quick for a human to approve or reject.
- **Avoid reinventing.** Many requests ("let users undo", "notify subscribers", "support a new storage backend") map onto known structures with known pitfalls.
- **Resist pattern inflation.** The checklists on each page exist to stop an agent from turning a 20-line function into five classes.

See [Using this reference as an agent](https://aipatterns.dev/guides/for-agents.md) for the full workflow.

## What not to expect

- Patterns do not make a design correct. A wrong abstraction behind a well-named pattern is still wrong.
- Patterns are not a checklist to maximize. Code with zero named patterns can be excellent.
- Patterns are not language-neutral in cost. Some vanish in languages with closures, generics or pattern matching. See [History of patterns](https://aipatterns.dev/guides/history-of-patterns.md).

## How to learn them efficiently

1. Read the intent and the "Do not use it when" section of every pattern first. That gives you recognition and restraint.
2. Learn the frequently seen ones in depth: [Strategy](https://aipatterns.dev/design-patterns/strategy.md), [Observer](https://aipatterns.dev/design-patterns/observer.md), [Adapter](https://aipatterns.dev/design-patterns/adapter.md), [Decorator](https://aipatterns.dev/design-patterns/decorator.md), [Factory Method](https://aipatterns.dev/design-patterns/factory-method.md), [Builder](https://aipatterns.dev/design-patterns/builder.md), [Facade](https://aipatterns.dev/design-patterns/facade.md).
3. Learn the confusable pairs side by side: Strategy vs State, Decorator vs Proxy, Adapter vs Facade, Factory Method vs Abstract Factory ([Factory comparison](https://aipatterns.dev/guides/factory-comparison.md)).
4. Practice by refactoring toward a pattern from a real smell, not by writing one from scratch.