Overview of Creational, Structural, and Behavioral Design Patterns

Creational Patterns

Factory Method

Intent: Define an interface for creating an object, letting subclasses decide which class to instantiate.

Applicability: When a class cannot anticipate the concrete class it must create, or wants subclasses to specify the created objects.

Abstract Factory

Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Applicability: When a system must be independent of how its products are created, composed, and represented, or when you need to enforce a set of related objects.

Builder

Intent: Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.

Applicability: When the algorithm for creating a complex object should be independent of its parts and assembly, or when different representations of the object are required.

Prototype

Intent: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Applicability: When the concrete classes to instantiate are specified at runtime, or when avoiding a parallel class hierarchy for factories, or when a limited set of object states can be efficiently cloned.

Singleton

Intent: Ensure a class has only one instance and provide a global point of access to it.

Applicability: When exactly one instance is needed and clients need a well-known access point, or when the single instance must be extensible via subclassing.

Structural Patterns

Adapter

Intent: Convert the interface of a class into another interface clients expect.

Applicability: When you need to use an existing class whose interface does not match your needs, or when you want to create a reusable class that can work with unrelated or unforeseen classes.

Bridge

Intent: Decouple an abstraction from its implementation so that the two can vary independently.

Applicability: When you want to avoid a permanent binding between abstraction and implementation, or when both should be extensible independently.

Composite

Intent: Compose objects into tree structures to represent part‑whole hierarchies; clients treat individual objects and compositions uniformly.

Applicability: When you need to represent part‑whole hierarchies and want clients to ignore differences between compositions and leaves.

Decorator

Intent: Dynamically add responsibilities to an object without affecting other objects.

Applicability: When you need to extend functionality transparently and avoid subclass explosion.

Facade

Intent: Provide a unified interface to a set of interfaces in a subsystem, making the subsystem easier to use.

Applicability: When you want to simplify a complex subsystem for most clients while still allowing advanced usage.

Flyweight

Intent: Use sharing to support large numbers of fine‑grained objects efficiently.

Applicability: When an application uses many objects that share common intrinsic state, reducing memory consumption.

Proxy

Intent: Provide a surrogate or placeholder for another object to control access to it.

Applicability: When you need a remote, virtual, protection, or smart reference to an object, or want to add additional behavior when accessing the real object.

Behavioral Patterns

Interpreter

Intent: Define a representation for a grammar and an interpreter that uses this representation to interpret sentences.

Applicability: When you have a simple language to interpret and can represent sentences as an abstract syntax tree.

Template Method

Intent: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses.

Applicability: When you want to implement invariant parts of an algorithm once and allow subclasses to customize specific steps.

Chain of Responsibility

Intent: Give more than one object a chance to handle a request, avoiding coupling the sender to a specific receiver.

Applicability: When multiple objects may handle a request and the handler should be selected at runtime.

Command

Intent: Encapsulate a request as an object, allowing parameterization of clients with queues, logs, and undoable operations.

Applicability: When you need to parameterize objects with actions, support undo/redo, or queue requests.

Iterator

Intent: Provide a way to access elements of an aggregate object sequentially without exposing its underlying representation.

Applicability: When you need to traverse a collection without exposing its internal structure, or support multiple traversal strategies.

Mediator

Intent: Define an object that encapsulates how a set of objects interact, promoting loose coupling.

Applicability: When a set of objects communicate in complex ways, leading to tangled dependencies.

Memento

Intent: Capture and externalize an object’s internal state without violating encapsulation, allowing the object to be restored later.

Applicability: When you need to restore an object to a previous state without exposing its internals.

Observer

Intent: Define a one‑to‑many dependency so that when one object changes state, all its dependents are notified and updated automatically.

Applicability: When an object’s change requires updating other objects without knowing how many or which objects are affected.

State

Intent: Allow an object to alter its behavior when its internal state changes, appearing to change its class.

Applicability: When an object’s behavior depends on its state and must change at runtime, often replacing large conditional statements.

Strategy

Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable.

Applicability: When you need to vary an algorithm independently from clients that use it, or to avoid exposing complex data structures.

Visitor

Intent: Represent an operation to be performed on elements of an object structure without changing the classes of the elements.

Applicability: When you need to perform many unrelated operations on a set of objects without polluting their classes.