Classification of Design Patterns

Classification of Design Patterns

The 23 classic patterns from the "Gang of Four" (GoF) book are not a flat list to memorise — they are organised along one axis that tells you what part of your design a pattern touches. Knowing the classification is the difference between reciting names and reaching for the right tool under interview pressure.

1. Intuition — why a classification exists

A pattern is a named, reusable solution to a recurring design problem. Once you have two dozen of them, you need a filing system, otherwise recall becomes brute-force. The GoF classify patterns by purpose: which design concern they address. Three concerns recur in almost every object-oriented system:

• How objects get created — hiding new, controlling instantiation, decoupling clients from concrete classes.
• How objects are composed — assembling classes and objects into larger structures without rigid inheritance.
• How objects collaborate — the runtime flow of messages and responsibility between objects.

Those three concerns give the three families: Creational, Structural, and Behavioral. The intuition is that any design pain you feel usually maps cleanly to exactly one of them, so the classification is a fast index from symptom to candidate patterns.

2. Precise definition — the three families

Creational patterns abstract the instantiation process so a system is independent of how its objects are created, composed, and represented. Examples: Factory Method, Abstract Factory, Builder, Prototype, Singleton. Signal: you see sprawling new ConcreteX() or giant constructors and want to isolate the choice of concrete type.

Structural patterns describe how classes and objects are combined to form larger structures while keeping them flexible and efficient. Examples: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Signal: you need to make incompatible interfaces work together, add responsibilities, or simplify a subsystem — the emphasis is on composition.

Behavioral patterns characterise how objects distribute responsibility and communicate at runtime. Examples: Strategy, Observer, Command, State, Template Method, Chain of Responsibility, Iterator, Mediator, Visitor, Memento, Interpreter. Signal: the pain is in control flow, algorithm selection, or who-talks-to-whom, not in construction or wiring.

A second, orthogonal axis the GoF add is scope: whether the pattern operates on classes (relationships fixed at compile time via inheritance) or on objects (relationships established at runtime via composition, generally more flexible). Most patterns are object-scoped.

3. Concrete example — one problem, one pattern per family

Imagine a payment service. Watch how the same domain surfaces all three concerns, each answered by a different family.

// CREATIONAL (Factory Method): isolate the choice of concrete gateway
interface PaymentGateway { Receipt charge(long cents); }

abstract class GatewayFactory {
    abstract PaymentGateway create();          // subclasses decide the type
}
class StripeFactory extends GatewayFactory {
    PaymentGateway create() { return new StripeGateway(); }
}

// STRUCTURAL (Adapter): make a legacy API fit our interface
class LegacyPayPal { void sendPayment(double dollars) { /* ... */ } }
class PayPalAdapter implements PaymentGateway {
    private final LegacyPayPal legacy = new LegacyPayPal();
    public Receipt charge(long cents) {
        legacy.sendPayment(cents / 100.0);      // translate the call
        return new Receipt();
    }
}

// BEHAVIORAL (Strategy): swap the retry algorithm at runtime
interface RetryPolicy { boolean retry(int attempt); }
class PaymentProcessor {
    private final PaymentGateway gateway;
    private final RetryPolicy retryPolicy;      // injected behavior
    PaymentProcessor(PaymentGateway g, RetryPolicy r) {
        this.gateway = g; this.retryPolicy = r;
    }
}

The classification tells you where each pattern plugs in: Factory at the construction boundary, Adapter at the integration boundary, Strategy at the behavior-selection boundary. They compose without overlapping.

4. When to use / when NOT — the judgment layer

The classification is a diagnostic shortcut, not a mandate. Use it like this:

• Reach for Creational when the concrete type is a decision you want to defer or centralise. But not for trivial objects — a plain new or a static factory method beats a full Abstract Factory when there is only one implementation. The alternative (dependency injection frameworks) often subsumes creational patterns entirely.
• Reach for Structural when you must integrate or extend without editing existing code (Open/Closed). Adapter vs Decorator vs Proxy look similar — all wrap an object — but differ by intent: Adapter changes the interface, Decorator adds behavior with the same interface, Proxy controls access with the same interface. Naming the intent, not the shape, is what interviewers reward.
• Reach for Behavioral when the variation is in algorithm or flow. Strategy vs State is the classic trap: identical structure, different intent — Strategy's variants are interchangeable and client-chosen; State's transitions are internal and self-driven. Template Method vs Strategy: the former varies steps via inheritance (class scope), the latter via composition (object scope, more flexible).

When NOT to classify at all: if you cannot state the recurring problem in one sentence, you are pattern-hunting, and forcing a category adds indirection with no payoff. Simple code that reads well always beats a pattern applied for its own sake.

5. Pitfalls — what interviewers probe

• Confusing purpose with mechanism. Many patterns share the same code shape (a wrapper, an interface + implementations). Interviewers ask "how is Decorator different from Proxy?" precisely because the classification is by intent. Answer with intent, not UML.
• Treating the families as rigid silos. A pattern can lean two ways — Iterator is behavioral but built on structural traversal; Command mixes object creation with behavior. The classification is the primary concern, not the only one.
• Missing the scope axis. Strong candidates mention class- vs object-scope and note that composition (object scope) is usually preferred over inheritance (class scope) for flexibility — a direct callback to "favor composition over inheritance."
• Over-engineering. The senior signal is knowing when a pattern is overkill. Interviewers plant scenarios where a Singleton hides global state or a Factory wraps a single class — say so.
• Not connecting to SOLID. Creational patterns serve Dependency Inversion; Structural serve Open/Closed; Behavioral serve Single Responsibility. Tying the family to the principle it upholds shows depth.

Key takeaways

• GoF patterns are classified by purpose into three families: Creational (object creation), Structural (object composition), Behavioral (object collaboration).
• A second, orthogonal scope axis splits patterns into class-scoped (inheritance, compile-time) and object-scoped (composition, runtime); object scope is usually more flexible.
• The classification is a fast symptom → candidate index: construction pain, integration pain, or flow pain each point to one family.
• Patterns that share a shape differ by intent — Adapter changes an interface, Decorator adds behavior, Proxy controls access; Strategy is client-chosen while State is self-driven.
• Each family maps to a SOLID principle: Creational↔Dependency Inversion, Structural↔Open/Closed, Behavioral↔Single Responsibility.
• The senior signal is restraint: name the recurring problem first, and skip the pattern when plain code is clearer.