Classification of Patterns

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.

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.

• Factory Method: let a subclass or function decide which concrete product to create.
• Abstract Factory: create families of related products that must match.
• Builder: assemble a complex object step by step.
• Prototype: create new objects by copying a configured instance.
• Singleton: guarantee one instance with a global access point.

Structural

Compose classes and objects into larger structures while keeping them flexible. See Structural patterns.

• Adapter: make one interface usable where another is expected.
• Bridge: split an abstraction from its implementation so both vary.
• Composite: treat trees of objects like single objects.
• Decorator: add behavior by wrapping an object with the same interface.
• Facade: give a simple front to a complex subsystem.
• Flyweight: share common state across many small objects.
• Proxy: stand in for another object to control access to it.

Behavioral

Assign responsibilities and define how objects communicate. See Behavioral patterns.

• Chain of Responsibility: pass a request along handlers until one deals with it.
• Command: turn a request into an object you can queue, log or undo.
• Iterator: traverse a collection without exposing its structure.
• Mediator: route communication through one coordinator.
• Memento: capture and restore state without breaking encapsulation.
• Observer: notify subscribers when something changes.
• State: change behavior when internal state changes.
• Strategy: swap interchangeable algorithms.
• Template Method: fix an algorithm's skeleton and let steps vary.
• Visitor: 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).

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, Observer, Adapter, Facade, Decorator, Builder, Factory Method, Iterator (usually built in).
• Regularly, for specific needs: Command, State, Composite, Proxy, Chain of Responsibility, Template Method, Abstract Factory.
• Rarely, and with care: Singleton, Mediator, Memento, Prototype, Bridge, Flyweight, Visitor.

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 and State: same delegation shape, different reason for switching.
• Decorator and Proxy: both wrap an object with the same interface; one adds behavior, the other controls access.
• Adapter and Facade: both wrap; one converts an interface, the other simplifies a subsystem.
• Factory Method and Abstract Factory: see Factory comparison.
• Composite and Visitor: often used together; see Visitor and double dispatch.

To pick among them from a symptom rather than a category, use Choosing a pattern.