Creational patterns answer one question: who decides which concrete class gets built? Factory says: not the caller.

Imagine a checkout flow that needs to charge a customer. Somewhere, code has to write new StripeGateway() or new PayPalGateway() or new WireTransferGateway(). The question is: where? If the answer is "scattered across every controller, every service, every place a payment happens to occur," you have a problem — the moment you add a fourth payment provider, or the business rule for choosing one changes, you're hunting through the entire codebase for every new SomeGateway() call.

The Factory Pattern family exists to answer a deceptively simple question: who decides which concrete class gets constructed, and where does that decision live? Instead of every caller making that decision independently, one place makes it — a factory — and everyone else just asks for "the right thing" without knowing or caring how it's built.

In this lesson, you'll learn the three recognized flavors of the Factory pattern — Simple Factory, Factory Method, and Abstract Factory — how they differ, when each one earns its complexity, and how they relate to something you already use every day: the DI container.

What Is It?

The Simple Explanation

A factory is code whose entire job is deciding which concrete class to instantiate and handing back the result — usually through a common interface or base type — so that the calling code never has to write new ConcreteClassName() itself, or even know that class name exists.

This is a Creational pattern — one of the three GoF categories covered in the design patterns lesson earlier in this Part. Creational patterns are all about controlling and centralizing how objects get created, as opposed to Structural patterns (how objects are composed) or Behavioral patterns (how objects communicate).

The Technical Definition — Three Related, Distinct Patterns

"Factory" isn't one single pattern — it's a family of three, each solving a slightly different shaped problem. Getting them straight matters, because mixing up their names is one of the most common mistakes developers make when discussing design patterns:

Why Does It Exist? — The Problem It Solves

Without a factory, object creation logic — often full of conditionals — leaks into every place that needs an object:

//  WITHOUT a factory — this conditional is copy-pasted everywhere a gateway is needed
public async Task<PaymentResult> CheckoutAsync(Order order, string paymentMethod)
{
    IPaymentGateway gateway = paymentMethod switch
    {
        "stripe" => new StripeGateway(_stripeApiKey),
        "paypal" => new PayPalGateway(_payPalClientId, _payPalSecret),
        "wire" => new WireTransferGateway(_bankRoutingInfo),
        _ => throw new NotSupportedException($"Unknown payment method: {paymentMethod}")
    };
    return await gateway.ChargeAsync(order.Total);
}
// Every controller, every background job, every place a payment happens
// now needs to know EVERY concrete gateway class, its constructor arguments,
// and the full up-to-date list of valid paymentMethod strings.

This has three concrete costs: the construction logic is duplicated everywhere a gateway is needed; every caller is coupled to every concrete gateway class and its constructor signature, even callers that only ever use one of them; and adding a new payment method means hunting down and editing every duplicate of that switch statement.

Big Picture

All three flavors share the same shape: the caller depends on an abstraction and asks a factory for an instance of it — the caller never writes the concrete class name.

How It Works

Simple Example

public interface IPaymentGateway
{
    Task<PaymentResult> ChargeAsync(decimal amount);
}

public sealed class StripeGateway(string apiKey) : IPaymentGateway
{
    public Task<PaymentResult> ChargeAsync(decimal amount) =>
        Task.FromResult(PaymentResult.Success("stripe-txn-id"));
}

public sealed class PayPalGateway(string clientId, string secret) : IPaymentGateway
{
    public Task<PaymentResult> ChargeAsync(decimal amount) =>
        Task.FromResult(PaymentResult.Success("paypal-txn-id"));
}

// ── The Simple Factory: one method, one decision, centralized ──
public static class PaymentGatewayFactory
{
    public static IPaymentGateway Create(string paymentMethod) => paymentMethod switch
    {
        "stripe" => new StripeGateway(Config.StripeApiKey),
        "paypal" => new PayPalGateway(Config.PayPalClientId, Config.PayPalSecret),
        _ => throw new NotSupportedException($"Unknown payment method: {paymentMethod}")
    };
}

// ── Usage — the caller never writes a concrete class name ──
IPaymentGateway gateway = PaymentGatewayFactory.Create(order.PaymentMethod);
var result = await gateway.ChargeAsync(order.Total);

Code → Meaning → Result: PaymentGatewayFactory.Create is the single place that knows both concrete class names and their constructor requirements. The calling code above only ever mentions IPaymentGateway. Add a fourth payment method tomorrow, and exactly one file changes — the factory. Every caller keeps working, unmodified.

Real-World Example — Notification Sender Selection

The same shape shows up constantly for notification systems, where the "right" sender depends on user preference or channel configuration read at runtime:

public interface INotificationSender
{
    Task SendAsync(string recipient, string message);
}

public sealed class EmailSender : INotificationSender { /* SMTP details */ }
public sealed class SmsSender : INotificationSender { /* SMS gateway details */ }
public sealed class PushSender : INotificationSender { /* push provider details */ }

// A factory that's itself a small injectable class — not just static methods —
// so it can depend on configuration and be unit tested like anything else.
public sealed class NotificationSenderFactory(IOptions<NotificationSettings> settings)
{
    public INotificationSender CreateFor(NotificationChannel channel) => channel switch
    {
        NotificationChannel.Email => new EmailSender(),
        NotificationChannel.Sms   => new SmsSender(),
        NotificationChannel.Push  => new PushSender(),
        _ => throw new NotSupportedException($"Unsupported channel: {channel}")
    };
}

// ── Usage in an OrderShippedHandler ──
public sealed class OrderShippedHandler(NotificationSenderFactory senderFactory)
{
    public async Task HandleAsync(Order order, NotificationChannel preferredChannel)
    {
        var sender = senderFactory.CreateFor(preferredChannel);
        await sender.SendAsync(order.CustomerContact, $"Order {order.Id} has shipped!");
    }
}

Notice the factory here is itself a small, DI-friendly class rather than a bag of static methods — that's a deliberate, common variation: the factory can take dependencies of its own (like configuration), and the factory itself can be registered and injected, without changing the pattern's fundamental shape.

Factory Method — The Same Idea, Through Inheritance

Factory Method solves a related but distinct problem: a base class defines an algorithm's overall shape, but wants subclasses to control which concrete type one step of that algorithm produces:

public abstract class ReportGenerator
{
    // The algorithm — fixed, lives in the base class, never overridden
    public string Generate(ReportData data)
    {
        var exporter = CreateExporter();          // ← the "factory method"
        var body = exporter.Export(data);
        return $"--- Report: {DateTime.UtcNow:d} ---\n{body}";
    }

    protected abstract IReportExporter CreateExporter();  // subclasses decide WHAT gets created
}

public sealed class PdfReportGenerator : ReportGenerator
{
    protected override IReportExporter CreateExporter() => new PdfExporter();
}

public sealed class CsvReportGenerator : ReportGenerator
{
    protected override IReportExporter CreateExporter() => new CsvExporter();
}

// ReportGenerator.Generate never changes; only WHICH exporter gets built varies by subclass.
ReportGenerator generator = new PdfReportGenerator();
string report = generator.Generate(data);

The difference from Simple Factory is mechanical but important: there's no switch statement anywhere — the "decision" is made by which subclass you instantiated, and enforced by the compiler through abstract/override. This is genuinely the Template Method pattern (a fixed algorithm skeleton with pluggable steps) applied specifically to object creation.

Analogy — Ordering at a Restaurant

Under the Hood — Abstract Factory's Mechanics, and the DI Container as Factory

An Abstract Factory looks like this — one interface exposing several "create" methods, with a concrete implementation per compatible family:

public interface IUiThemeFactory
{
    IButton CreateButton();
    ICheckbox CreateCheckbox();
}

public sealed class DarkThemeFactory : IUiThemeFactory
{
    public IButton CreateButton() => new DarkButton();
    public ICheckbox CreateCheckbox() => new DarkCheckbox();
}

public sealed class LightThemeFactory : IUiThemeFactory
{
    public IButton CreateButton() => new LightButton();
    public ICheckbox CreateCheckbox() => new LightCheckbox();
}
// Whichever IUiThemeFactory you're handed, CreateButton() and CreateCheckbox()
// are GUARANTEED to return matching-theme widgets — no accidental Dark button
// next to a Light checkbox.

Common Confusion

"Isn't a DI container just a giant Factory Method?"

Close, but not quite — a DI container is closer to a generalized Simple Factory operating over your whole application, resolved by type rather than a hand-written switch. Factory Method specifically requires inheritance — a base class calling an abstract/virtual creation step that a subclass overrides. A DI container doesn't use inheritance to decide what to construct; it uses a registration lookup. Both are still "Factory family" ideas — object creation is centralized and abstracted away from the consumer — but they're mechanically different patterns.

"Simple Factory isn't a 'real' GoF pattern — does that matter?"

Not for practical purposes. The original 1994 GoF catalog lists Factory Method and Abstract Factory, but not "Simple Factory" by that exact name — it's usually described as an idiom, or a simplified stepping stone toward Factory Method. In everyday conversation and in code reviews, "factory" almost always means this simple, centralized-conditional shape, and that's fine — just know that if someone asks you to name the 23 GoF patterns, "Simple Factory" isn't one of the official ones.

Common Mistakes

Mistake 1 — Building a factory when a DI container registration already does the job

Writing GatewayFactory.Create(gatewayType) when there's really only ever going to be one IPaymentGateway implementation active per environment, chosen once at startup — that's not a runtime decision that needs a factory, it's just a registration: services.AddScoped<IPaymentGateway, StripeGateway>(). Reach for a hand-written factory specifically when the decision genuinely happens per-call, based on data only available at that moment (like order.PaymentMethod) — not when it's a fixed, environment-wide choice the container already handles for free.

Mistake 2 — Letting the factory's switch statement grow without bound and violating Open/Closed

Every new payment method means editing the switch inside PaymentGatewayFactory.Create directly — which is fine at 3 or 4 cases, but at 20 becomes a genuine maintenance hotspot everyone touches. For a large or frequently-growing family, consider registering gateways in the DI container keyed by a discriminator and resolving via IEnumerable<IPaymentGateway> plus a matching property on each implementation — trading a hand-written switch for container-driven lookup.

Mistake 3 — Reaching for Abstract Factory when there's no real "family" to keep consistent

Building a full IUiThemeFactory-style abstraction with multiple Create...() methods when you only ever need to create one kind of object — that's Simple Factory or Factory Method wearing unnecessary Abstract Factory ceremony. Abstract Factory earns its complexity specifically when multiple related objects must be created together and must stay compatible with each other — if there's no compatibility constraint between the objects, you don't need the family concept at all.

When Should I Use It?

• Simple Factory — when the concrete type to create depends on data available only at the call site (a string, an enum, a request field), and that decision would otherwise be duplicated across many callers.
• Factory Method — when you have a fixed algorithm in a base class, and only the "what gets created" part should vary by subclass; it fits naturally when you're already using inheritance for the rest of the class's behavior.
• Abstract Factory — when you must create several related objects together and guarantee they're mutually compatible — cross-platform UI toolkits and multi-provider infrastructure (e.g., "all Azure resources" vs. "all AWS resources" for a given deployment) are the classic cases.

And when it's overkill: if there's genuinely only one implementation of an interface that will ever exist in a given environment, a plain DI container registration already is your factory — writing a dedicated factory class on top adds a layer with nothing left to decide. Don't build a factory "just in case" a second implementation shows up someday; add it when the second implementation actually exists.

Mental Model

Key Takeaway

Check Your Understanding

You've seen all three flavors of Factory and how the DI container relates. Let's check you can tell them apart and know when each earns its keep.

You now know all three Factory variants, when each earns its complexity, and how your DI container has been quietly acting as a factory for your entire object graph all along.

dotnetmadeeasy.com — Learn C# and .NET, the right way.