Software Design Patterns: Creational, Structural, and Behavioral

Software design patterns are reusable solutions to recurring structural and behavioral problems in object-oriented software design. Originally catalogued by the "Gang of Four" — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — in their 1994 publication Design Patterns: Elements of Reusable Object-Oriented Software, the 23 canonical patterns remain the baseline vocabulary of professional software architecture across enterprise, mobile, and systems development. This page covers the classification structure, mechanical operation, tradeoffs, and professional application of all three pattern families: creational, structural, and behavioral.

Definition and scope

Design patterns occupy a specific layer of the software engineering knowledge hierarchy. They are neither algorithms (which specify exact computational procedures) nor frameworks (which provide runnable infrastructure). A design pattern names a proven structural arrangement of classes or objects that solves a recognized design problem while remaining adaptable to different implementation contexts.

The IEEE Software Engineering Body of Knowledge (SWEBOK v4), maintained by the IEEE Computer Society, classifies design patterns within the Software Design knowledge area and recognizes them as a primary mechanism for achieving design quality attributes — specifically modularity, reusability, and maintainability. SWEBOK frames patterns as design strategies that encode accumulated engineering judgment, not arbitrary stylistic preferences.

The scope of canonical patterns is bounded at 23 in the original Gang of Four taxonomy, organized into 3 families. Pattern literature has expanded well beyond this set — enterprise integration patterns, concurrency patterns, and cloud-native patterns now form separate catalogs — but the GoF 23 remain the foundational reference set that professional certification bodies and academic curricula treat as core competency. Practitioners working across software architecture patterns and broader system design contexts routinely draw on these foundational pattern families as compositional units within larger architectural decisions.

Core mechanics or structure

Each of the 3 pattern families addresses a distinct phase or dimension of object-oriented design.

Creational patterns govern object instantiation — specifically, how objects are created and which classes are responsible for creation decisions. The 5 GoF creational patterns are: Abstract Factory, Builder, Factory Method, Prototype, and Singleton. The unifying mechanic is the decoupling of a client from the concrete classes it depends upon. Factory Method, for example, defines an interface for object creation but defers the decision about which class to instantiate to subclasses, eliminating direct constructor calls from client code.

Structural patterns define how classes and objects are composed to form larger structures. The 7 GoF structural patterns are: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, and Proxy. These patterns address compile-time class composition (through inheritance) and runtime object composition (through delegation). The Facade pattern, for instance, provides a simplified interface to a complex subsystem, reducing the coupling surface between subsystem components and the clients that consume them.

Behavioral patterns define the communication protocols and responsibility assignments between objects at runtime. The 11 GoF behavioral patterns are: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, and Visitor. The Observer pattern — used extensively in event-driven UI frameworks and reactive systems — establishes a one-to-many dependency so that when one object changes state, all registered dependents are notified automatically without tight coupling.

The formal structure of any GoF pattern includes 4 elements: the pattern name, the problem it addresses, the solution (a description of the arrangement of classes and objects), and the consequences (tradeoffs and results of applying the pattern). This 4-part structure, documented in the original 1994 text, standardizes how patterns are communicated across teams and codebases.

Causal relationships or drivers

The adoption of design patterns as a professional discipline is driven by 3 structural forces in software development: complexity growth, team size, and knowledge transfer costs.

Complexity growth emerges as systems accumulate features. Without systematic design strategies, codebases develop tight coupling between components — a condition that the ACM identifies in its computing education curricula as a primary source of long-term maintenance cost. Patterns provide pre-analyzed structural solutions that limit coupling propagation at the design stage.

Team size amplifies the value of shared pattern vocabulary. A team of 12 engineers communicating through pattern names ("use a Strategy here instead of a conditional chain") achieves design alignment faster than teams relying on informal or ad hoc descriptions. The Software Engineering Institute (SEI) at Carnegie Mellon University has documented vocabulary standardization as a measurable factor in reducing design review time on large-scale software projects.

Knowledge transfer costs are reduced when patterns encode expert design judgment in a transmissible form. Junior engineers working on object-oriented programming principles can apply patterns before independently developing the intuition that produced them, compressing the gap between novice and experienced design decisions.

Enterprise application development — the segment covered in depth by App Development Authority, a reference covering architectural patterns, governance frameworks, and qualification standards for enterprise mobile and web applications — applies creational and structural patterns extensively in service layer design, dependency injection containers, and API abstraction layers. That resource addresses how patterns interact with enterprise-grade constraints such as scalability requirements, compliance obligations, and multi-team governance.

Classification boundaries

The 3 GoF families are mutually exclusive by intent but not always mutually exclusive in implementation. A single pattern can exhibit characteristics of multiple families, which creates professional debate about correct classification.

The Proxy pattern is classified as structural because it controls access to another object through a surrogate. However, Proxy implementations in security contexts add behavioral logic (logging, access validation) that overlaps with behavioral pattern territory. This boundary ambiguity is acknowledged in the original GoF text — the authors note that pattern intent, not implementation mechanics, determines classification.

The Template Method (behavioral) and Factory Method (creational) patterns share inheritance-based mechanics but differ in intent: Template Method governs algorithmic step sequence; Factory Method governs object creation. Misclassifying one as the other leads to misapplication — particularly when developers apply Template Method to creation problems where Factory Method's client-decoupling benefits are needed.

Pattern scope — class-level versus object-level — provides a second classification axis orthogonal to the family axis. Class-scope patterns use inheritance to fix relationships at compile time; object-scope patterns use composition to establish relationships at runtime. Of the 23 GoF patterns, the majority are object-scope, reflecting the GoF's documented preference for composition over inheritance, a principle also foundational to the SOLID principles framework that governs professional OOP design standards.

Tradeoffs and tensions

Pattern adoption carries documented costs that practitioners must weigh against the structural benefits.

Abstraction overhead is the primary tension. Every layer of indirection introduced by a pattern — an abstract factory interface, a mediator object, a proxy wrapper — adds cognitive load for developers reading the code. A codebase that applies patterns to every design decision becomes harder to navigate than one that reserves patterns for genuinely complex structural problems. The GoF authors explicitly caution against "pattern overuse" in the original text.

Premature pattern application creates architectures that are over-engineered relative to actual requirements. Applying the Abstract Factory pattern to a system that will only ever instantiate one concrete product family adds interface complexity without delivering the flexibility the pattern was designed to provide. This failure mode is closely related to technical debt accumulation through unnecessary abstraction — the debt manifests as maintenance burden when the abstraction layers must be unwound.

Language-specific relevance is a tension that the original GoF text — written against C++ and Smalltalk — does not address for modern languages. In Python and JavaScript, first-class functions and dynamic typing render patterns like Strategy, Command, and Iterator less structurally necessary, because the language natively supports the behaviors those patterns encode in statically typed languages. The Gang of Four patterns were not designed to be language-agnostic; applying them uniformly across language contexts produces unnecessary complexity.

Pattern misidentification in code review and documentation produces false design assurance. Labeling a class "Manager" or "Factory" without implementing the full structural contract of the corresponding pattern misleads collaborators about the code's actual behavior. This issue intersects directly with code review best practices, where reviewers must distinguish genuine pattern implementation from superficial naming conventions.

Common misconceptions

Misconception: Design patterns are a prescriptive library to implement in every codebase.
Correction: Patterns are descriptive, not prescriptive. The GoF catalog documents solutions that have proven effective in specific problem contexts. No authoritative body — not IEEE, not ACM, not the SEI — mandates pattern implementation as a compliance requirement. Patterns are applied when the problem they address is actually present.

Misconception: The Singleton pattern is an anti-pattern.
Correction: Singleton is classified as a legitimate creational pattern with valid use cases — logging, configuration management, and device driver access. Its reputation as an anti-pattern derives from misapplication in contexts where shared global state creates testing and concurrency problems. The pattern itself is not flawed; inappropriate application to stateful, multi-threaded contexts without synchronization is the source of defects.

Misconception: All 23 GoF patterns are equally relevant to modern development.
Correction: Pattern relevance varies by programming paradigm and language. The Interpreter pattern, for example, is rarely applied in contemporary web or mobile development but remains relevant in compiler construction and domain-specific language (DSL) design. The Iterator pattern is largely subsumed by built-in language iteration protocols in Python, Java, and C#. Functional programming in software engineering eliminates the need for patterns like Strategy and Command in many contexts by representing behavior as first-class values.

Misconception: Design patterns and architectural patterns are the same category.
Correction: Design patterns operate at the class and object level within a single application module. Architectural patterns — such as Model-View-Controller, Event-Driven Architecture, and Microservices — operate at the system level, governing inter-component and inter-service structure. Software architecture patterns represent a distinct abstraction tier above the GoF pattern catalog.

Checklist or steps (non-advisory)

The following sequence describes the professional process of identifying, selecting, and implementing a design pattern against a recognized software design problem.

  1. Problem identification — Document the specific structural or behavioral problem: tight coupling, conditional proliferation, object creation complexity, or algorithm variation across contexts.
  2. Problem classification — Determine whether the problem is fundamentally about object creation (creational), composition of structures (structural), or runtime communication (behavioral).
  3. Pattern candidate selection — Within the applicable family, identify candidate patterns whose stated problem statements match the documented problem. The GoF "Intent" and "Applicability" sections of each pattern provide the formal matching criteria.
  4. Consequence review — Evaluate the documented tradeoffs of the candidate pattern: what flexibility it adds, what complexity it introduces, and which design principles it satisfies or compromises.
  5. Language-context validation — Confirm that the pattern adds structural value in the target language and paradigm. Assess whether language features (first-class functions, generics, reflection) already provide the benefit the pattern encodes.
  6. Structural implementation — Implement the pattern's class and object arrangement, preserving the full structural contract — not merely the naming conventions.
  7. Documentation — Record the applied pattern by name, the problem it addresses, and the rationale for selection in code comments or architectural decision records (ADRs). This record supports software documentation standards and future maintenance.
  8. Verification — Confirm through code review that the implementation satisfies the pattern's stated intent — not just its surface structure — and that no unintended coupling has been introduced.

The software engineering reference index provides the broader professional context in which these pattern application decisions occur, including the full range of engineering practices, career standards, and qualification frameworks that govern the discipline.

Reference table or matrix

Pattern Family Scope Primary Problem Addressed Key Tradeoff
Abstract Factory Creational Object Create families of related objects without specifying concrete classes Difficult to extend product families; requires modifying interfaces
Builder Creational Object Separate construction of complex objects from representation Requires dedicated Builder class per product type
Factory Method Creational Class Defer subclass instantiation decision to subclasses Requires subclassing; may lead to class proliferation
Prototype Creational Object Create new objects by copying existing instances Deep vs. shallow copy ambiguity; cloning complexity
Singleton Creational Object Ensure single instance with global access point Introduces global state; complicates unit testing
Adapter Structural Class/Object Convert incompatible interface to expected interface Double indirection; performance overhead
Bridge Structural Object Decouple abstraction from implementation Increases up-front design complexity
Composite Structural Object Treat individual objects and compositions uniformly Overly general design; harder to restrict component types
Decorator Structural Object Add responsibilities to objects dynamically Produces many small objects; complex debugging
Facade Structural Object Simplify interface to complex subsystem Does not prevent direct subsystem access
Flyweight Structural Object Share objects to support large numbers efficiently Introduces shared state; requires careful management
Proxy Structural Object Control access to another object Additional indirection; complexity for simple cases
Chain of Responsibility Behavioral Object Pass request along chain of handlers No guarantee of request handling
Command Behavioral Object Encapsulate request as object Proliferation of command classes
Interpreter Behavioral Class Define grammar and interpreter for a language Inefficient for complex grammars
Iterator Behavioral Object Access aggregate elements sequentially without exposing structure Native language iteration often supersedes
Mediator Behavioral Object Define object that encapsulates how objects interact Mediator can become a monolithic complexity hub
Memento Behavioral Object Capture and restore object state High memory cost for frequent state snapshots
Observer Behavioral Object Notify dependents of state changes automatically Unexpected cascading updates; memory leaks in weak-reference models
State Behavioral Object Allow object to alter behavior when internal state changes Class count grows with state count
Strategy Behavioral Object Define family of algorithms; make them interchangeable Client must be aware of different strategies
Template Method Behavioral Class Define skeleton of algorithm; defer steps to subclasses Inheritance-based; limits runtime flexibility
Visitor Behavioral Object Define new operation on elements without changing their classes Adding new element types requires modifying all visitors

References

Read Next

Software Architecture Patterns: MVC, Microservices, Monolith, and More This page covers the major recognized patterns, their classification boundaries, the tradeoffs that make pattern selection... Object-Oriented Programming Principles in Software Engineering This page describes the four foundational principles of OOP, how they operate mechanically within a codebase, the professional... SOLID Principles: Writing Maintainable Object-Oriented Code Each principle targets a distinct failure mode — from classes that grow bloated with unrelated responsibilities to modules...