Article

Design Patterns: Creational, Structural, and Behavioral Overview

Q: What are design patterns?

Reusable solutions to common design problems. Templates (not copy-paste code) grouped into Creational, Structural, Behavioral.

Q: What is Creational?

How objects are created: deferring creation, reusing instances, abstracting construction. Examples: Factory Method, Builder, Singleton.

Q: What is Structural?

How objects are composed into larger structures: wrapping interfaces, simplifying subsystems, sharing state. Examples: Adapter, Decorator, Facade.

Q: What is Behavioral?

How objects interact and distribute responsibility: notifying observers, switching algorithms, encapsulating requests. Examples: Observer, Strategy, Command.

Q: What is the difference between Creational, Structural, and Behavioral?

Creational = how objects are created. Structural = how objects are composed. Behavioral = how objects interact and share responsibility.

Q: When should I use a design pattern?

Use a pattern when it solves a recurring problem and makes the design clearer. Do not force a pattern where a simple solution suffices.

Q: Should I use Singleton?

Use Singleton only when you truly need one instance globally (e.g. logger, config). Prefer dependency injection and a single registered instance.

Q: What is Factory Method vs Abstract Factory?

Factory Method: one method creates one product; subclasses decide the concrete type. Abstract Factory: family of factories for related products.

Q: What is Decorator vs Adapter?

Decorator adds behaviour without changing interface. Adapter changes the interface of an existing object to match what the client expects.

Q: What is Strategy vs State?

Strategy: switch algorithms at runtime; context delegates to strategy. State: object behaviour depends on internal state; state object encapsulates state-specific behaviour.

Design patterns overview: Creational, Structural, Behavioral, and .NET fit.

November 14, 2024 · Waqas Ahmad

Read the article

Introduction

This guidance is relevant when the topic of this article applies to your system or design choices; it breaks down when constraints or context differ. I’ve applied it in real projects and refined the takeaways over time (as of 2026).

Recurring design problems—object creation, composition, and interaction—often get solved ad hoc unless you use shared templates that make intent and structure clear. This article gives an overview of the three main categories (Creational, Structural, Behavioral), when to use which, and how they fit in .NET; full code and use cases are in the dedicated Creational, Structural, and Behavioral articles. For architects and tech leads, using patterns where they fit improves clarity and consistency; overusing them adds noise.

If you are new to design patterns, start with Topics covered and Design patterns overview at a glance.

For more on .NET and architecture, see the .NET Architecture resource.

Topics covered

Decision Context
What are design patterns and why they matter
Design patterns overview at a glance
Creational in depth (overview)
Structural in depth (overview)
Behavioral in depth (overview)
Comparison: Creational vs Structural vs Behavioral
When to use which category
Where patterns live in a .NET solution

Decision Context

System scale: Varies by context; the approach in this article applies to the scales and scenarios described in the body.
Team size: Typically small to medium teams; ownership and clarity matter more than headcount.
Time / budget pressure: Applicable under delivery pressure; I’ve used it in both greenfield and incremental refactors.
Technical constraints: .NET and related stack where relevant; constraints are noted in the article where they affect the approach.
Non-goals: This article does not optimize for every possible scenario; boundaries are stated where they matter.

What are design patterns and why they matter

Design patterns are recurring solutions to recurring design problems. They come from the Gang of Four (GoF) book and are grouped into Creational (how objects are created), Structural (how objects are composed), and Behavioral (how objects interact and share responsibility). They are not libraries or frameworks—they are templates that you apply in your code to improve flexibility, maintainability, and communication between developers.

Why they matter: Using patterns helps you avoid reinventing the wheel, name common designs so teams can discuss them quickly, and keep code decoupled and testable. Overusing patterns or forcing them where a simple solution suffices can make code harder to read; use them when they simplify the design and match the problem.

Design patterns overview at a glance

Category	Focus	When to use	Example patterns
Creational	How objects are created	Decouple creation, reuse instances, abstract construction	Factory Method, Abstract Factory, Builder, Prototype, Singleton
Structural	How objects are composed	Build larger structures, wrap/adapt, simplify interfaces	Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral	How objects interact	Distribute responsibility, notify, switch algorithms	Observer, Strategy, Command, State, Template Method, Chain of Responsibility

Loading diagram…

Creational in depth (overview)

Creational patterns deal with how objects are created: deferring creation to a method or subclass (Factory Method), to a family of factories (Abstract Factory), to a step-by-step builder (Builder), by cloning (Prototype), or by ensuring a single instance (Singleton). They help decouple client code from concrete types and creation logic.

For all five creational patterns with class diagrams, when to use each, and full C# examples, see the dedicated article: Creational Design Patterns in .NET.

Structural in depth (overview)

Structural patterns deal with how objects are composed into larger structures: wrapping one interface to match another (Adapter), separating abstraction from implementation (Bridge), treating trees uniformly (Composite), adding behavior dynamically (Decorator), simplifying a subsystem (Facade), sharing state to save memory (Flyweight), and providing a placeholder or access control (Proxy).

For all seven structural patterns with class diagrams, when to use each, and full C# examples, see the dedicated article: Structural Design Patterns in .NET.

Behavioral in depth (overview)

Behavioral patterns deal with how objects interact and distribute responsibility: notifying observers (Observer), switching algorithms at runtime (Strategy), encapsulating requests (Command), modeling state-dependent behavior (State), defining a skeleton algorithm (Template Method), passing requests along a chain (Chain of Responsibility), and others (Iterator, Mediator, Memento, Interpreter, Visitor).

For all eleven behavioral patterns with class diagrams, when to use each, and full C# examples, see the dedicated article: Behavioral Design Patterns in .NET.

Comparison: Creational vs Structural vs Behavioral

Category	Focus	When to use	Example patterns
Creational	How objects are created	Decouple creation, reuse instances, abstract construction	Factory Method, Abstract Factory, Builder, Prototype, Singleton
Structural	How objects are composed	Build larger structures, wrap/adapt, simplify interfaces	Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral	How objects interact	Distribute responsibility, notify, switch algorithms	Observer, Strategy, Command, State, Template Method, Chain of Responsibility

When to use which category

Creational: Use when the creation of objects is complex, varies by context, or you need to control instantiation (e.g. Factory for different document types, Builder for optional parameters, Singleton for a single shared instance).
Structural: Use when you need to compose or wrap types: adapt an existing interface (Adapter), add behavior without subclassing (Decorator), hide a complex subsystem (Facade), or control access (Proxy).
Behavioral: Use when communication or flow of control is the concern: one object notifies many (Observer), you want to swap algorithms (Strategy), encapsulate a request (Command), or model state-dependent behavior (State).

Where patterns live in a .NET solution

In a typical .NET solution that applies design patterns, interfaces and concrete types are grouped by feature or layer; patterns are reflected in how types depend on each other, not necessarily in folder names. Creational patterns appear in factories and builders (often in Composition/DI); Structural in adapters, decorators, facades (often in Infrastructure); Behavioral in handlers, strategies, state classes (often in Core or Application).

MyApp.sln
  src/MyApp/
    Core/                    # Interfaces, domain (Strategy, Command, State)
    Infrastructure/          # Adapters, external APIs (Adapter, Proxy)
    Application/             # Use cases, orchestration (Facade, Template Method)
    Composition/             # DI registration (Factory, Builder, Singleton via DI)

How they interact: Core defines interfaces (e.g. IDocument, IDiscountStrategy). Infrastructure implements adapters and proxies. Application uses facades and template methods to orchestrate. Composition (e.g. Program.cs or a DI module) wires factories and singletons. For full code and class diagrams for each pattern, see Creational in .NET, Structural in .NET, Behavioral in .NET.

Quick code examples (one per category)

Creational (Factory Method in C#): A base class defines a factory method; subclasses create the concrete product. The client depends on the abstraction, not the concrete type.

public abstract class DocumentProcessor {
    public void Process() {
        var doc = CreateDocument();
        doc.Load();
        doc.Transform();
    }
    protected abstract IDocument CreateDocument();
}
public class PdfProcessor : DocumentProcessor {
    protected override IDocument CreateDocument() => new PdfDocument();
}

Structural (Decorator in C#): Wrap a component to add behaviour without changing its interface. Each decorator holds a reference to the inner component and delegates, then adds its own logic.

public interface IOrderService { Task<Order> GetByIdAsync(string id); }
public class LoggingOrderService : IOrderService {
    private readonly IOrderService _inner;
    public LoggingOrderService(IOrderService inner) => _inner = inner;
    public async Task<Order> GetByIdAsync(string id) {
        Console.WriteLine("GetOrder " + id);
        return await _inner.GetByIdAsync(id);
    }
}

Behavioral (Strategy in C#): Inject an algorithm so the same context can use different strategies at runtime. The context calls the strategy interface; tests and production can swap implementations.

public interface IDiscountStrategy { decimal Apply(decimal amount); }
public class OrderCalculator {
    private readonly IDiscountStrategy _strategy;
    public OrderCalculator(IDiscountStrategy strategy) => _strategy = strategy;
    public decimal Total(decimal subtotal) => _strategy.Apply(subtotal);
}
// Register in DI: AddScoped<IDiscountStrategy, PercentDiscountStrategy>()

For every pattern with full C# examples and class diagrams, see the dedicated articles: Creational, Structural, Behavioral.

Best practices and pitfalls

Overusing patterns: Not every class needs a pattern. Use patterns when they simplify design and communication; avoid pattern-heavy code that is harder to read.

Misusing Singleton: Singleton can make testing and concurrency hard. Prefer dependency injection and a single registered instance (e.g. AddSingleton<T>) so tests can replace it.

Confusing similar patterns: Factory vs Abstract Factory (one product vs family), Strategy vs State (algorithm vs state transitions), Decorator vs Adapter (add behaviour vs change interface)—pick the one that matches the problem.

Where patterns fit: In Clean Architecture, Creational patterns live in composition/DI; Structural in adapters and infrastructure; Behavioral in use cases and domain.

Summary

Design patterns are reusable templates grouped into Creational, Structural, and Behavioral; use them when they solve a recurring problem and improve clarity. Overusing patterns adds noise; applying them where they fit helps architects and teams communicate and keep structure consistent. Next, pick one recurring design problem in your codebase, match it to a category (Creational/Structural/Behavioral), then open the dedicated .NET article for that pattern and apply it where it fits.

Design patterns are reusable templates for common design problems, grouped into Creational (object creation), Structural (composition), and Behavioral (interaction and responsibility). Use them when they solve a recurring problem and make the design clearer. This overview gives the big picture and when to use which category; for full code, class diagrams, and use cases for each pattern, see Creational in .NET, Structural in .NET, and Behavioral in .NET.

Position & Rationale

I use patterns when they match a recurring problem and make the design clearer—not when they’re a goal in themselves. I favour Creational (Factory, Builder, DI) for construction, Structural (Adapter, Decorator, Facade) for composition and wrapping, Behavioral (Strategy, Observer, Command, State) for interaction and flow. I avoid applying every pattern everywhere; a simple conditional or delegate often suffices. I also avoid memorising the catalog without understanding when each pattern fits; the overview (Creational vs Structural vs Behavioral) is the map—the dedicated articles are the implementation.

Trade-Offs & Failure Modes

What this sacrifices: Extra types and indirection; each pattern adds structure. In return you get clarity and consistency when the problem recurs.
Where it degrades: When patterns are applied for their own sake (“we need a Factory here”) and the problem doesn’t justify them; or when the team doesn’t recognise the pattern and adds ad hoc logic.
How it fails when misapplied: Strategy for two branches that never change; or Singleton for something that should be testable. Another failure: mixing similar patterns (e.g. Strategy vs State) without clarity.
Early warning signs: “We have a pattern but we never vary it”; “nobody knows why we use this abstraction.”

What Most Guides Miss

Most guides list patterns. The hard part is when to skip: not every creation needs a Factory, not every state machine needs the full State pattern. The other gap: Creational vs Structural vs Behavioral as a decision tree—start with “is this about creation, composition, or interaction?” and then narrow. Finally: fit with Clean Architecture—patterns live in layers (composition, adapters, use cases); don’t force a pattern that breaks the dependency rule.

Decision Framework

If the problem is “how do we create this?” → Creational: Factory, Builder, Singleton, Abstract Factory; choose by complexity and who decides the type.
If the problem is “how do we compose or wrap?” → Structural: Adapter, Decorator, Facade; choose by whether you’re changing interface or adding behaviour.
If the problem is “how do objects interact or who does what?” → Behavioral: Strategy, Observer, Command, State, Mediator; choose by whether you’re swapping logic, notifying, queuing, or managing state.
If you’re not sure → Read the overview and the dedicated article (Creational/Structural/Behavioral in .NET); match the problem to the pattern’s intent.
If the pattern doesn’t fit → Prefer a simple solution; add the pattern when the problem recurs or when clarity suffers.

Key Takeaways

Creational = creation; Structural = composition/wrapping; Behavioral = interaction/responsibility; use the category to narrow the choice.
Apply patterns when they solve a recurring problem and improve clarity; avoid applying them for their own sake.
Match the problem to the pattern’s intent; when in doubt, see the dedicated .NET articles for full code and when-to-use.
Patterns fit in Clean Architecture: Creational in DI, Structural in adapters, Behavioral in use cases and domain.
Simple conditionals or delegates often suffice; add structure when the problem recurs or when the design is hard to follow.

Need architectural guidance for real-world .NET platforms? I offer consulting for .NET architecture, API platforms, and enterprise system design.

When I Would Use This Again — and When I Wouldn’t

I would use this overview again when I’m introducing design patterns or deciding which category (Creational, Structural, Behavioral) fits a problem—then drill into the dedicated articles for full code. I wouldn’t use it as a substitute for the detailed .NET articles when I need implementation. I also wouldn’t force a pattern when a simple solution works; the overview is a map, not a mandate. Alternative: for experienced teams that already know the catalog, use it as a quick “which category?” reference and jump to the pattern that fits.

Frequently Asked Questions

What are design patterns?

Design patterns are reusable solutions to common problems in software design. They are templates (not copy-paste code) for structuring code. The GoF defined 23 patterns in three categories: Creational, Structural, Behavioral.

What is Creational?

Creational patterns are about how objects are created: deferring creation, reusing instances, abstracting construction. Examples: Factory Method, Builder, Prototype, Singleton. See Creational patterns in .NET for code and comparison.

What is Structural?

Structural patterns are about how objects are composed into larger structures: wrapping interfaces, simplifying subsystems, sharing state. Examples: Adapter, Decorator, Facade, Proxy. See Structural patterns in .NET for code and comparison.

What is Behavioral?

Behavioral patterns are about how objects interact and distribute responsibility: notifying observers, switching algorithms, encapsulating requests. Examples: Observer, Strategy, Command, State, Template Method. See Behavioral patterns in .NET for code and comparison.

What is the difference between Creational, Structural, and Behavioral?

Creational = how objects are created. Structural = how objects are composed into larger structures. Behavioral = how objects interact and share responsibility.

When should I use a design pattern?

Use a pattern when it solves a recurring problem in your codebase and makes the design clearer. Do not force a pattern where a simple solution suffices.

Should I use Singleton?

Use Singleton only when you truly need one instance globally (e.g. logger, config). Prefer dependency injection and registering a single instance in the container so tests can replace it.

What is Factory Method vs Abstract Factory?

Factory Method: one method creates one product; subclasses decide the concrete type. Abstract Factory: a family of factories for related products. Use Factory Method for one product; Abstract Factory for families.

What is Decorator vs Adapter?

Decorator adds behaviour to an object without changing its interface. Adapter changes the interface of an existing object to match what the client expects. Both wrap; Decorator adds behaviour, Adapter changes interface.

What is Strategy vs State?

Strategy: switch algorithms at runtime; the context delegates to the strategy. State: object behaviour depends on internal state; state object encapsulates state-specific behaviour. Strategy is about algorithm; State is about state transitions.

What is Observer vs Pub/Sub?

Observer: one-to-many; subject notifies observers directly (in-process). Pub/Sub: decoupled; publisher and subscriber do not know each other; message broker in between (often across services).

When should I use Builder?

Use Builder when object construction is complex (many optional parameters, steps). Builder separates construction from representation and makes the API readable (e.g. fluent API).

What is Facade used for?

Facade provides a simple interface to a complex subsystem. Use it when you want to hide complexity and give clients one entry point. Common in APIs and service layers.

What is Command pattern used for?

Command encapsulates a request as an object. Use for undo/redo, queues, macros, or when you need to parameterise operations (e.g. delay execution, log, replay).

How do design patterns fit with Clean Architecture?

Patterns live in layers: Creational in composition/DI; Structural in adapters and infrastructure; Behavioral in use cases and domain. Clean Architecture defines boundaries; patterns implement them.

Where can I find full .NET code for each pattern?

See the dedicated articles: Creational in .NET, Structural in .NET, Behavioral in .NET. Each has class diagrams, use cases, and full C# examples with file-level detail.

Related Guides & Resources

Part of cluster

Full-Stack & Data — explore related topics:

Full Stack Development Database Design & Optimization

Waqas Ahmad — Software Architect & Technical Consultant

Distributed Systems

Article

Design Patterns: Creational, Structural, and Behavioral Overview

Read the article

Introduction

Topics covered

Decision Context

What are design patterns and why they matter

Design patterns overview at a glance

Creational in depth (overview)

Structural in depth (overview)

Behavioral in depth (overview)

Comparison: Creational vs Structural vs Behavioral

When to use which category

Where patterns live in a .NET solution

Quick code examples (one per category)

Best practices and pitfalls

Summary

Position & Rationale

Trade-Offs & Failure Modes

What Most Guides Miss

Decision Framework

Key Takeaways

When I Would Use This Again — and When I Wouldn’t

Frequently Asked Questions

Frequently Asked Questions

What are design patterns?

What is Creational?

What is Structural?

What is Behavioral?

What is the difference between Creational, Structural, and Behavioral?

When should I use a design pattern?

Should I use Singleton?

What is Factory Method vs Abstract Factory?

What is Decorator vs Adapter?

What is Strategy vs State?

What is Observer vs Pub/Sub?

When should I use Builder?

What is Facade used for?

What is Command pattern used for?

How do design patterns fit with Clean Architecture?

Where can I find full .NET code for each pattern?

Related Guides & Resources

Related articles

Part of cluster

Related services