# Classification of Patterns

> How the 22 classic design patterns are grouped by purpose into creational, structural and behavioral, plus other useful ways to slice them.

- kind: guide
- category: design-patterns
- aliases: Pattern categories
- canonical: https://aipatterns.dev/guides/classification-of-patterns
- inspired-by: https://refactoring.guru/design-patterns/classification

## Three groups by purpose

The classic catalog sorts patterns by the kind of problem they solve. **Ask what you are trying to control: object creation, object composition, or the flow of responsibility between objects.**

```mermaid
flowchart TD
  Q[What is the design problem about?] --> C[How objects get created]
  Q --> S[How objects fit together]
  Q --> B[How objects divide work and communicate]
  C --> CR[Creational]
  S --> ST[Structural]
  B --> BE[Behavioral]
```

### Creational

Control how and when objects are created, so callers don't depend on concrete classes or construction details. See [Creational patterns](https://aipatterns.dev/design-patterns/creational.md).

- [Factory Method](https://aipatterns.dev/design-patterns/factory-method.md): let a subclass or function decide which concrete product to create.
- [Abstract Factory](https://aipatterns.dev/design-patterns/abstract-factory.md): create families of related products that must match.
- [Builder](https://aipatterns.dev/design-patterns/builder.md): assemble a complex object step by step.
- [Prototype](https://aipatterns.dev/design-patterns/prototype.md): create new objects by copying a configured instance.
- [Singleton](https://aipatterns.dev/design-patterns/singleton.md): guarantee one instance with a global access point.

### Structural

Compose classes and objects into larger structures while keeping them flexible. See [Structural patterns](https://aipatterns.dev/design-patterns/structural.md).

- [Adapter](https://aipatterns.dev/design-patterns/adapter.md): make one interface usable where another is expected.
- [Bridge](https://aipatterns.dev/design-patterns/bridge.md): split an abstraction from its implementation so both vary.
- [Composite](https://aipatterns.dev/design-patterns/composite.md): treat trees of objects like single objects.
- [Decorator](https://aipatterns.dev/design-patterns/decorator.md): add behavior by wrapping an object with the same interface.
- [Facade](https://aipatterns.dev/design-patterns/facade.md): give a simple front to a complex subsystem.
- [Flyweight](https://aipatterns.dev/design-patterns/flyweight.md): share common state across many small objects.
- [Proxy](https://aipatterns.dev/design-patterns/proxy.md): stand in for another object to control access to it.

### Behavioral

Assign responsibilities and define how objects communicate. See [Behavioral patterns](https://aipatterns.dev/design-patterns/behavioral.md).

- [Chain of Responsibility](https://aipatterns.dev/design-patterns/chain-of-responsibility.md): pass a request along handlers until one deals with it.
- [Command](https://aipatterns.dev/design-patterns/command.md): turn a request into an object you can queue, log or undo.
- [Iterator](https://aipatterns.dev/design-patterns/iterator.md): traverse a collection without exposing its structure.
- [Mediator](https://aipatterns.dev/design-patterns/mediator.md): route communication through one coordinator.
- [Memento](https://aipatterns.dev/design-patterns/memento.md): capture and restore state without breaking encapsulation.
- [Observer](https://aipatterns.dev/design-patterns/observer.md): notify subscribers when something changes.
- [State](https://aipatterns.dev/design-patterns/state.md): change behavior when internal state changes.
- [Strategy](https://aipatterns.dev/design-patterns/strategy.md): swap interchangeable algorithms.
- [Template Method](https://aipatterns.dev/design-patterns/template-method.md): fix an algorithm's skeleton and let steps vary.
- [Visitor](https://aipatterns.dev/design-patterns/visitor.md): add operations over a structure without editing its classes.

## A second axis: class vs object scope

The original catalog also asked whether a pattern works mainly through inheritance (class scope, fixed at compile time) or through composition (object scope, changeable at runtime).

| Scope | Mechanism | Examples |
|---|---|---|
| Class | Subclassing | [Factory Method](https://aipatterns.dev/design-patterns/factory-method.md), [Template Method](https://aipatterns.dev/design-patterns/template-method.md), class-form [Adapter](https://aipatterns.dev/design-patterns/adapter.md) |
| Object | Composition and delegation | [Strategy](https://aipatterns.dev/design-patterns/strategy.md), [Decorator](https://aipatterns.dev/design-patterns/decorator.md), [Bridge](https://aipatterns.dev/design-patterns/bridge.md), [Observer](https://aipatterns.dev/design-patterns/observer.md), most others |

Prefer object-scope patterns by default. They change at runtime, test more easily, and avoid deep hierarchies.

## A third axis: how often you need them

Grouping by frequency is more useful day to day than grouping by purpose:

- **Everywhere**: [Strategy](https://aipatterns.dev/design-patterns/strategy.md), [Observer](https://aipatterns.dev/design-patterns/observer.md), [Adapter](https://aipatterns.dev/design-patterns/adapter.md), [Facade](https://aipatterns.dev/design-patterns/facade.md), [Decorator](https://aipatterns.dev/design-patterns/decorator.md), [Builder](https://aipatterns.dev/design-patterns/builder.md), [Factory Method](https://aipatterns.dev/design-patterns/factory-method.md), [Iterator](https://aipatterns.dev/design-patterns/iterator.md) (usually built in).
- **Regularly, for specific needs**: [Command](https://aipatterns.dev/design-patterns/command.md), [State](https://aipatterns.dev/design-patterns/state.md), [Composite](https://aipatterns.dev/design-patterns/composite.md), [Proxy](https://aipatterns.dev/design-patterns/proxy.md), [Chain of Responsibility](https://aipatterns.dev/design-patterns/chain-of-responsibility.md), [Template Method](https://aipatterns.dev/design-patterns/template-method.md), [Abstract Factory](https://aipatterns.dev/design-patterns/abstract-factory.md).
- **Rarely, and with care**: [Singleton](https://aipatterns.dev/design-patterns/singleton.md), [Mediator](https://aipatterns.dev/design-patterns/mediator.md), [Memento](https://aipatterns.dev/design-patterns/memento.md), [Prototype](https://aipatterns.dev/design-patterns/prototype.md), [Bridge](https://aipatterns.dev/design-patterns/bridge.md), [Flyweight](https://aipatterns.dev/design-patterns/flyweight.md), [Visitor](https://aipatterns.dev/design-patterns/visitor.md).

Each pattern page carries `popularity` and `complexity` scores (1 to 3) in its frontmatter for the same purpose.

## Confusable neighbors across groups

Groups are not walls. Some patterns share a structure but differ in intent:

- [Strategy](https://aipatterns.dev/design-patterns/strategy.md) and [State](https://aipatterns.dev/design-patterns/state.md): same delegation shape, different reason for switching.
- [Decorator](https://aipatterns.dev/design-patterns/decorator.md) and [Proxy](https://aipatterns.dev/design-patterns/proxy.md): both wrap an object with the same interface; one adds behavior, the other controls access.
- [Adapter](https://aipatterns.dev/design-patterns/adapter.md) and [Facade](https://aipatterns.dev/design-patterns/facade.md): both wrap; one converts an interface, the other simplifies a subsystem.
- [Factory Method](https://aipatterns.dev/design-patterns/factory-method.md) and [Abstract Factory](https://aipatterns.dev/design-patterns/abstract-factory.md): see [Factory comparison](https://aipatterns.dev/guides/factory-comparison.md).
- [Composite](https://aipatterns.dev/design-patterns/composite.md) and [Visitor](https://aipatterns.dev/design-patterns/visitor.md): often used together; see [Visitor and double dispatch](https://aipatterns.dev/guides/visitor-and-double-dispatch.md).

To pick among them from a symptom rather than a category, use [Choosing a pattern](https://aipatterns.dev/guides/choosing-a-pattern.md).