Abstract Factory

BMW's "3 Series" factory line produces a 3-Series engine, 3-Series chassis, and 3-Series interior — all engineered to fit together precisely. The "7 Series" line produces a completely different set of parts. You can't bolt a 3-Series engine into a 7-Series chassis — the parts are family-specific. Each production line is a Concrete Factory creating a coordinated product family.

Choose the Apple ecosystem and you get iPhone + AirPods + Apple Watch — all seamlessly syncing via iCloud. Choose Google and you get Pixel + Pixel Buds + Wear OS watch — syncing via Google services. Products within each ecosystem are designed to work together. Mixing AirPods with a Pixel technically works, but you lose the family-specific features (seamless pairing, ecosystem sync).

An Italian kitchen produces Italian appetizer + Italian main + Italian dessert — flavors, ingredients, and presentation are consistent. A Japanese kitchen produces a completely different coordinated set. You don't order an Italian appetizer followed by a Japanese main — the Abstract Factory (restaurant concept) ensures each kitchen (Concrete Factory) delivers a complete, consistent meal experience.

Two major additions: generics enabled type-safe abstract factories without casting, and DbProviderFactory was introduced as the canonical Abstract Factory in the .NET framework.
Each database vendor (SQL Server, Oracle, OleDb) shipped a concrete factory creating family-consistent Connection, Command, and DataAdapter objects — configurable via app.config.

// .NET 2.0 — DbProviderFactory: THE canonical Abstract Factory
DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");
DbConnection conn = factory.CreateConnection();      // SqlConnection
DbCommand cmd = factory.CreateCommand();              // SqlCommand
DbDataAdapter adapter = factory.CreateDataAdapter();  // SqlDataAdapter

// .NET 2.0 — Generic Abstract Factory, type-safe, no casting
public interface IFactory<TProductA, TProductB>
    where TProductA : IProductA
    where TProductB : IProductB
{
    TProductA CreateProductA();
    TProductB CreateProductB();
}

public sealed class WinFactory
    : IFactory<WinButton, WinCheckbox>
{
    public WinButton CreateProductA() => new WinButton();
    public WinCheckbox CreateProductB() => new WinCheckbox();
}

Third-party IoCInversion of Control — a principle where the framework calls your code (not the other way around). DI containers are the most common IoC mechanism. containers — Unity, Autofac, Ninject — arrived with .NET 3.5. Then .NET 4.0 added MEFManaged Extensibility Framework — .NET's built-in plugin/composition system using [Export] and [Import] attributes for dependency discovery. Shipped with .NET 4.0. (Managed Extensibility Framework) as a built-in plugin system. Abstract Factory implementations shifted from manual hierarchies to container-managed registrations.

// MEFManaged Extensibility Framework — a .NET library for composing applications from discoverable parts (plugins), using attributes like [Export] and [Import]. — plugin-based factory discovery
[Export(typeof(IUIFactory))]
[ExportMetadata("Platform", "windows")]
public sealed class WinFactory : IUIFactory
{
    public IButton CreateButton() => new WinButton();
    public ICheckbox CreateCheckbox() => new WinCheckbox();
}

// Autofac — keyed registration (predecessor of .NET 8 keyed services)
var builder = new ContainerBuilder();
builder.RegisterType<WinFactory>().Keyed<IUIFactory>("windows");
builder.RegisterType<MacFactory>().Keyed<IUIFactory>("mac");
var container = builder.Build();

// Resolve by key
var factory = container.ResolveKeyed<IUIFactory>("windows");

Microsoft shipped a built-in DI container with IServiceCollectionThe .NET interface for registering services and their lifetimes (Singleton, Scoped, Transient) in the built-in dependency injection container.. Manual abstract factory classes became less necessary — the container itself acts as a factory. Patterns shifted to registering Func<string, IFactory> delegates or using IServiceProvider to resolve families.

// .NET Core DI — factory delegate pattern
services.AddSingleton<WinFactory>();
services.AddSingleton<MacFactory>();

// Register a resolver delegate (workaround — no keyed services yet)
services.AddSingleton<Func<string, IUIFactory>>(sp => key => key switch
{
    "windows" => sp.GetRequiredService<WinFactory>(),
    "mac" => sp.GetRequiredService<MacFactory>(),
    _ => throw new ArgumentException($"Unknown platform: {key}")
});

// Usage — inject the delegate
public class Renderer(Func<string, IUIFactory> factoryResolver)
{
    public string Render(string platform)
    {
        var factory = factoryResolver(platform);
        return factory.CreateButton().Paint();
    }
}

WebApplicationBuilder and minimal APIsA .NET 6+ feature for building HTTP APIs with minimal boilerplate — using lambda expressions directly in Program.cs instead of controllers. simplified registration.
IHttpClientFactoryA .NET factory that creates pre-configured HttpClient instances with proper lifecycle management — prevents socket exhaustion and DNS issues. demonstrated framework-level Abstract Factory usage — each named client creates a family of HttpClient + handler pipeline + retry policies.
EF Core providers continued as the cleanest AF example.

// .NET 6 — IHttpClientFactory: Abstract Factory for HTTP clients
// Each named client = family of HttpClient + handlers + policies
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpClient("github", c =>
{
    c.BaseAddress = new Uri("https://api.github.com/");
    c.DefaultRequestHeaders.Add("Accept", "application/json");
})
.AddHttpMessageHandler<RetryHandler>();   // Family includes retry

// EF Core provider = Abstract Factory for database services
builder.Services.AddDbContext<AppDbContext>(opts =>
    opts.UseNpgsql(connString)); // Swaps 30+ internal service family

var app = builder.Build();
var client = app.Services.GetRequiredService<IHttpClientFactory>()
    .CreateClient("github"); // Gets complete family

Keyed services (AddKeyed*) eliminated the need for custom factory delegates. FrozenDictionary.NET 8+ read-only dictionary optimized for fast lookups after one-time construction — ideal for factory registries that don't change at runtime. optimized factory registries. Source generatorsCompile-time code generation in C# that produces source code during compilation, avoiding runtime reflection overhead. enabled AOTAhead-of-Time compilation — compiling code to native machine code before runtime, eliminating JIT overhead and reducing startup time.-friendly factories without reflection.

// .NET 8+ — first-class keyed services (no workarounds!)
builder.Services.AddKeyedSingleton<IUIFactory, WinFactory>("windows");
builder.Services.AddKeyedSingleton<IUIFactory, MacFactory>("mac");
builder.Services.AddKeyedSingleton<IUIFactory, LinuxFactory>("linux");

// Constructor injection by key — clean and declarative
public class Renderer([FromKeyedServices("mac")] IUIFactory factory)
{
    public string Render() => factory.CreateButton().Paint();
}

// FrozenDictionary.NET 8+ immutable dictionary optimized for read-heavy scenarios — keys are hashed at creation time, giving faster lookups than Dictionary<K,V> with zero per-lookup allocations. — optimal for static factory registries
var factories = new Dictionary<string, IUIFactory>
{
    ["windows"] = new WinFactory(),
    ["mac"] = new MacFactory()
}.ToFrozenDictionary();  // O(1) lookup, zero allocations after init

CultureInfo is a classic Abstract Factory: each culture creates a family of related formatting objects — NumberFormatInfo, DateTimeFormatInfo, TextInfo, CompareInfo — all guaranteed to be consistent for that locale.

Swap the culture, swap the entire family.

// Each CultureInfo = an Abstract Factory creating locale-consistent products
CultureInfo us = new("en-US");
NumberFormatInfo usNumbers = us.NumberFormat;     // Product A: "$1,234.56"
DateTimeFormatInfo usDates = us.DateTimeFormat;   // Product B: "3/5/2026"
TextInfo usText = us.TextInfo;                    // Product C: "HELLO"
CompareInfo usCompare = us.CompareInfo;           // Product D: ordinal sort

CultureInfo de = new("de-DE");                   // Swap factory → swap entire family
NumberFormatInfo deNumbers = de.NumberFormat;     // Product A: "1.234,56 €"
DateTimeFormatInfo deDates = de.DateTimeFormat;   // Product B: "05.03.2026"
TextInfo deText = de.TextInfo;                    // Product C: "HELLO" (but ß → SS)
CompareInfo deCompare = de.CompareInfo;           // Product D: locale-aware sort

// All four products from one culture are guaranteed compatible
// Mixing en-US numbers with de-DE dates = data corruption

IHttpClientFactoryA factory abstraction in Microsoft.Extensions.Http that manages HttpClient lifetimes and creates pre-configured client instances with named or typed configurations. is a textbook Abstract Factory: each named/typed client configuration creates a family of related objects — HttpClient + HttpMessageHandler pipeline + retry policies — all guaranteed to work together.

Swap the name, swap the entire family.

// Each named client = a FAMILY: HttpClient + handlers + policies
builder.Services.AddHttpClient("github", client =>
{
    client.BaseAddress = new Uri("https://api.github.com");
    client.DefaultRequestHeaders.Add("User-Agent", "MyApp");
})
.AddHttpMessageHandler<AuthTokenHandler>()    // Family member: auth handler
.AddStandardResilienceHandler();               // Family member: retry policy

builder.Services.AddHttpClient("stripe", client =>
{
    client.BaseAddress = new Uri("https://api.stripe.com");
})
.AddHttpMessageHandler<StripeAuthHandler>()   // Different family: different handler
.AddStandardResilienceHandler();               // Different retry config

// Consumer picks a family by name — gets all related objects
public class GitHubService(IHttpClientFactory factory)
{
    private readonly HttpClient _client = factory.CreateClient("github");
    // _client has GitHub base URL + auth handler + retry policy — complete family
}

Each EF Core database provider is an Abstract Factory that creates a family of compatible services: IRelationalConnection, ISqlGenerationHelper, IMigrationsSqlGenerator, IQuerySqlGeneratorFactory, and more.

Call UseSqlServer() vs UseNpgsql() and the entire family of 30+ internal services swaps as a unit.

// Each provider call registers an ENTIRE FAMILY of services
// SQL Server family
builder.Services.AddDbContext<AppDbContext>(opts =>
    opts.UseSqlServer(connString));   // Registers: SqlServerConnection,
                                      //   SqlServerSqlGenerator,
                                      //   SqlServerMigrationsSqlGenerator, etc.

// PostgreSQL family — swap one line, swap 30+ services
builder.Services.AddDbContext<AppDbContext>(opts =>
    opts.UseNpgsql(connString));      // Registers: NpgsqlConnection,
                                      //   NpgsqlSqlGenerator,
                                      //   NpgsqlMigrationsSqlGenerator, etc.

// SQLite family — same pattern, different family of products
builder.Services.AddDbContext<AppDbContext>(opts =>
    opts.UseSqlite(connString));      // Registers: SqliteConnection,
                                      //   SqliteSqlGenerator, etc.

// Your code never touches provider-specific types — pure Abstract Factory

IFileProvider creates a family of three related product types: IFileInfo (file metadata), IDirectoryContents (directory listing), and IChangeToken (change notifications).

Swap PhysicalFileProvider for EmbeddedFileProvider or ManifestEmbeddedFileProvider and the entire family changes — disk files vs embedded resources vs manifest resources.

// IFileProvider interface — 3 product types = Abstract Factory
public interface IFileProvider
{
    IFileInfo GetFileInfo(string subpath);           // Product A
    IDirectoryContents GetDirectoryContents(string subpath); // Product B
    IChangeToken Watch(string filter);               // Product C
}

// Family 1: Physical disk files
IFileProvider disk = new PhysicalFileProvider("/app/wwwroot");
IFileInfo file = disk.GetFileInfo("index.html");       // PhysicalFileInfo
IDirectoryContents dir = disk.GetDirectoryContents(""); // PhysicalDirectoryContents
IChangeToken watch = disk.Watch("**/*.css");            // PollingChangeToken

// Family 2: Embedded resources (compiled into DLL)
IFileProvider embedded = new EmbeddedFileProvider(typeof(Program).Assembly);
IFileInfo file2 = embedded.GetFileInfo("templates/email.html"); // EmbeddedResourceFileInfo
// All three products are guaranteed compatible within a family

IServiceProviderFactory<TContainerBuilder> is the Abstract Factory that creates the DI container itself.
The default implementation creates Microsoft's built-in container, but third-party libraries (Autofac, Lamar) provide their own factory creating a completely different family of container internals — scope management, resolution strategy, lifetime tracking — all swapped as a unit.

// Default family: Microsoft's built-in DI container
var builder = WebApplication.CreateBuilder(args);
// Uses DefaultServiceProviderFactory internally —
// creates: ServiceProvider + ServiceScope + ServiceScopeFactory

// Autofac family: swap one line, entire DI infrastructure changes
builder.Host.UseServiceProviderFactory(
    new AutofacServiceProviderFactory());
// Now creates: AutofacServiceProvider + LifetimeScope +
//   PropertyInjection + ModuleRegistration — different family!

builder.Host.ConfigureContainer<ContainerBuilder>(container =>
{
    container.RegisterModule<DataAccessModule>();
    container.RegisterModule<LoggingModule>();
});

// Your app code doesn't change — IServiceProvider is the abstraction
app.Services.GetRequiredService<IOrderService>(); // Works with any family

System.Text.Encoding is a textbook Abstract Factory: each encoding (UTF-8, Unicode, ASCII) creates a family of Encoder + Decoder + byte[] Preamble that are guaranteed compatible.
You can also register custom encoding families via EncodingProvider.

// Each Encoding = Abstract Factory creating compatible products
Encoding utf8 = Encoding.UTF8;
Encoder encoder = utf8.GetEncoder();      // Product A: UTF-8 encoder
Decoder decoder = utf8.GetDecoder();      // Product B: UTF-8 decoder
byte[] preamble = utf8.GetPreamble();     // Product C: UTF-8 BOM (EF BB BF)

Encoding unicode = Encoding.Unicode;       // Swap factory → swap family
Encoder enc2 = unicode.GetEncoder();       // Product A: UTF-16 encoder
Decoder dec2 = unicode.GetDecoder();       // Product B: UTF-16 decoder
byte[] pre2 = unicode.GetPreamble();       // Product C: UTF-16 BOM (FF FE)

// Mixing UTF-8 encoder with UTF-16 decoder = garbled text
// The factory guarantees you get a consistent family

// Register custom encoding families via EncodingProvider
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
Encoding shiftJis = Encoding.GetEncoding("shift_jis"); // New family!

Here is what happened step by step. A developer on the team split the UI creation into two separate interfaces: IButtonFactory for making buttons, and ICheckboxFactory for making checkboxes. On the surface, this seems reasonable — each interface has a single job, right? But the problem is that buttons and checkboxes on the same page must belong to the same visual family (both Windows-style or both macOS-style). Splitting the factory by product type destroys that guarantee.

During DI registrationDependency Injection registration — telling the DI container which concrete class to use when someone asks for an interface. Done at startup in Program.cs., one developer registered IButtonFactory pointing to the Windows implementation, while a different developer (working on a different feature) registered ICheckboxFactory pointing to the macOS implementation. Neither knew about the other's registration. The container happily resolved both — no complaints.

The checkout page injected both factories through its constructor. When it called btnFactory.Create(), it got a Windows-style button. When it called chkFactory.Create(), it got a macOS-style checkbox. The code compiled, ran without errors, and even passed unit tests (which tested each factory in isolation). But on screen, the result was a mismatched Frankenstein UI.

QA only caught it three hours later because the mismatch was subtle on most screen sizes. On a specific resolution, the Windows button and macOS checkbox had noticeably different heights, causing the layout to break visually. This is exactly the kind of "silent" bug that Abstract Factory is designed to prevent — when it is used correctly.

Time to Diagnose

3 hours — visual bug, no crash, only noticed by QA on specific screen resolution.

// ❌ Two different factories injected — families mixed!
public class CheckoutPage(
    IButtonFactory btnFactory,  // ❌ Resolves to WinButtonFactory
    ICheckboxFactory chkFactory) // ❌ Resolves to MacCheckboxFactory
{
    public void Render()
    {
        var btn = btnFactory.Create();   // WinButton
        var chk = chkFactory.Create();   // MacCheckbox — WRONG FAMILY!
    }
}

// ✅ Single Abstract Factory — guarantees family consistency
public class CheckoutPage(IUIFactory factory)
{
    public void Render()
    {
        var btn = factory.CreateButton();     // ✅ Same family
        var chk = factory.CreateCheckbox();   // ✅ Same family
    }
}

// ✅ Registration: ONE factory, not split per product
builder.Services.AddSingleton<IUIFactory, WinFactory>();

To understand this bug, you need to know how DI lifetimesHow long the DI container keeps an object alive. Singleton = forever, Scoped = one per request, Transient = new every time. work. In .NET, a "scoped" service (like DbContext) is supposed to be created fresh for each HTTP request and thrown away when the request ends. A "singleton" service lives for the entire lifetime of the application — it is created once and shared by every request.

The problem: the factory was registered as a singleton. It received a DbContext through its constructor. The DI container resolved that DbContext when the factory was first created (during the very first request). From that point on, the factory — and its captured DbContext — lived forever. Every subsequent request used the same DbContext, which still had the connection string and tenant context from request number one.

In development, nobody noticed because the developer was always logged in as the same tenant. In production, with hundreds of concurrent users across different tenants, the stale DbContext served data using the wrong tenant's connection. The bug was intermittent (it depended on which tenant's request happened to create the singleton first) and only appeared under concurrent load.

Think of it like this: imagine a restaurant where one waiter (the factory) picks up a notepad (the DbContext) on their first shift and never gets a new one. That notepad has "Table 5, chicken" written on it from Monday. On Tuesday, the waiter still reads from Monday's notepad and brings chicken to the wrong table. The notepad was supposed to be replaced every shift (every request), but because the waiter never leaves (singleton), they never get a fresh one.

Time to Diagnose

8 hours — intermittent, only under concurrent load, data appeared correct in dev.

// ❌ Singleton factory captures scoped DbContext
builder.Services.AddSingleton<IReportFactory, ReportFactory>();

public sealed class ReportFactory : IReportFactory
{
    private readonly AppDbContext _db; // ❌ Scoped! Captured by singleton!

    public ReportFactory(AppDbContext db) => _db = db;

    public IReport CreateReport(string type) =>
        new Report(_db.Reports.Where(r => r.Type == type));
    // ❌ _db is the SAME instance for ALL requests
    // ❌ Connection string from first request's tenant
}

// ✅ Factory takes IServiceScopeFactory — creates fresh scope per call
builder.Services.AddSingleton<IReportFactory, ReportFactory>();

public sealed class ReportFactory(IServiceScopeFactory scopeFactory)
    : IReportFactory
{
    public IReport CreateReport(string type)
    {
        // ✅ New scope = new DbContext = correct tenant
        var scope = scopeFactory.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        return new Report(db.Reports.Where(r => r.Type == type), scope);
    }
}

// ✅ Report disposes scope when done
public sealed class Report(IQueryable<ReportRow> data, IServiceScope scope)
    : IReport, IDisposable
{
    public void Dispose() => scope.Dispose();
}

Here is the sneaky detail. When the developer added CreateDropdown() to IUIFactory, they gave it a default interface methodA C# 8+ feature that lets interfaces provide a method body. Classes that implement the interface don't have to override it — they silently inherit the default. Useful for evolving interfaces without breaking existing code, but dangerous when the default hides missing implementations. that returned null!. In C#, a default interface method means existing classes that implement the interface do not have to add the new method — they just silently use the default. That is great for backward compatibility, but terrible when the "default" is a null that crashes at runtime.

The Windows factory (WinFactory) was updated in the same pull request that added the interface method. It properly returned a WinDropdown. But MacFactory was in a different file, maintained by a different team member. Nobody noticed it was missing the override. The compiler was happy — the default method satisfied the contract. All tests on the Windows path passed.

When a macOS user navigated to a page with a dropdown, the app called factory.CreateDropdown() on the Mac factory. The default method returned null!. The next line tried to call a method on that null dropdown — boom, NullReferenceException. The bug only affected one platform and one UI element, making it particularly tricky to catch in testing if you only tested on Windows.

Think of it like a restaurant adding a new dessert to the menu. The head chef at the Downtown location creates the recipe. The Uptown chef never gets the memo. When an Uptown customer orders the dessert, the waiter walks to the kitchen and comes back with nothing. The menu (interface) promises the dessert exists, but the kitchen (factory) cannot actually make it.

Time to Diagnose

30 minutes — NullReferenceException in production, but only on macOS clients.

public interface IUIFactory
{
    IButton CreateButton();
    ICheckbox CreateCheckbox();
    IDropdown CreateDropdown() => null!; // ❌ Default implementation hides the bug
}

public sealed class WinFactory : IUIFactory
{
    public IButton CreateButton() => new WinButton();
    public ICheckbox CreateCheckbox() => new WinCheckbox();
    public IDropdown CreateDropdown() => new WinDropdown(); // ✅ Implemented
}

public sealed class MacFactory : IUIFactory
{
    public IButton CreateButton() => new MacButton();
    public ICheckbox CreateCheckbox() => new MacCheckbox();
    // ❌ CreateDropdown() NOT overridden — returns null! at runtime
}

// ✅ Fix 1: Remove default — compiler forces all factories to implement
public interface IUIFactory
{
    IButton CreateButton();
    ICheckbox CreateCheckbox();
    IDropdown CreateDropdown(); // ✅ No default — compile error if missing
}

// ✅ Fix 2: Add a startup validation test
[Fact]
public void All_Factories_Implement_All_Products()
{
    var factoryTypes = typeof(IUIFactory).Assembly.GetTypes()
        .Where(t => typeof(IUIFactory).IsAssignableFrom(t) && !t.IsInterface);

    foreach (var type in factoryTypes)
    {
        var factory = (IUIFactory)Activator.CreateInstance(type)!;
        Assert.NotNull(factory.CreateButton());
        Assert.NotNull(factory.CreateCheckbox());
        Assert.NotNull(factory.CreateDropdown());
    }
}

This is the classic "magic string" problem. When you use raw strings as keys to register and resolve services, the compiler cannot check if the strings match. You can spell the key differently in two places and the compiler will not blink. The connection between the registration and the consumer is purely conventional — it only exists in the developer's head.

In this case, the developer who registered the factory wrote "postgres" (the short name). A different developer, working on the reporting feature weeks later, typed "postgresql" (the full name). Both strings are reasonable names for PostgreSQL. Neither developer did anything obviously wrong. But the key mismatch meant the DI container could not find a factory registered under "postgresql" because none existed — the factory was registered under "postgres".

The bug only triggered in production because the reporting endpoint was rarely used during development. Manual testing focused on the main CRUD operations, which did not use keyed services. The reporting feature sat quietly broken for two weeks before a customer hit it.

Think of it like labeling boxes in a warehouse. You label a box "DB-Postgres" and put it on shelf A. Your coworker comes looking for "DB-PostgreSQL." They search every shelf and find nothing — even though the box they need is right there, labeled slightly differently.

Time to Diagnose

15 minutes once triggered — but the bug sat in production for 2 weeks in a rarely-used code path.

// ❌ Magic strings — typo causes runtime failure
builder.Services.AddKeyedSingleton<IDbFactory, PostgresFactory>("postgres");

// Somewhere else in the codebase...
public class ReportService(
    [FromKeyedServices("postgresql")] IDbFactory factory) // ❌ TYPO!
{ }

// ✅ Use constants — single source of truth
public static class DbKeys
{
    public const string Postgres = "postgres";
    public const string SqlServer = "sqlserver";
}

builder.Services.AddKeyedSingleton<IDbFactory, PostgresFactory>(DbKeys.Postgres);

public class ReportService(
    [FromKeyedServices(DbKeys.Postgres)] IDbFactory factory) // ✅ Compile-safe
{ }

// ✅ Even better: use an enum
public enum DbProvider { Postgres, SqlServer }
builder.Services.AddKeyedSingleton<IDbFactory, PostgresFactory>(DbProvider.Postgres);

Imagine two people trying to introduce each other. Alice says "I can't introduce myself until Bob goes first." Bob says "I can't introduce myself until Alice goes first." Neither can ever start. That is exactly what happened with these two factories.

The DI container tried to build OrderFactory. To do that, it needed to inject IPaymentFactory, which meant building PaymentFactory. But PaymentFactory required IOrderFactory, which is what we were trying to build in the first place. The container detected the infinite loop and threw an exception. Unlike the other bugs on this page, this one at least fails loudly at startup — you cannot accidentally ship it to production. But it still blocked the team for two hours because untangling the design required real thought.

The root problem was a design flaw, not a coding mistake. The PaymentFactory did not actually need to create orders — it just needed to look up an existing order to validate it. That "look up" responsibility belonged in a simple repository, not in a factory. By giving PaymentFactory a dependency on the entire IOrderFactory, the team gave it far more power (and coupling) than it needed.

Time to Diagnose

2 hours — clear error message, but untangling the design took thought.

// ❌ Circular dependency — startup crash
public sealed class OrderFactory(IPaymentFactory payments) : IOrderFactory
{
    public IOrder Create(OrderRequest req)
    {
        var payment = payments.CreatePayment(req.PaymentInfo);
        return new Order(req, payment);
    }
}

public sealed class PaymentFactory(IOrderFactory orders) : IPaymentFactory
{
    public IPayment CreatePayment(PaymentInfo info)
    {
        var order = orders.GetOrder(info.OrderId); // ❌ Needs IOrderFactory!
        return new Payment(info, order);
    }
}

// ✅ Break the cycle — use Lazy<T> or extract shared concern
// Option 1: Lazy injection (quick fix)
public sealed class PaymentFactory(Lazy<IOrderFactory> orders) : IPaymentFactory
{
    public IPayment CreatePayment(PaymentInfo info)
    {
        var order = orders.Value.GetOrder(info.OrderId); // ✅ Resolved lazily
        return new Payment(info, order);
    }
}

// Option 2 (better): Extract the shared concern into a separate service
public interface IOrderRepository
{
    Order GetOrder(Guid id);
}

public sealed class PaymentFactory(IOrderRepository repo) : IPaymentFactory
{
    public IPayment CreatePayment(PaymentInfo info)
    {
        var order = repo.GetOrder(info.OrderId); // ✅ No factory dependency
        return new Payment(info, order);
    }
}

To understand this bug, you need to know one important rule: a regular Dictionary<TKey, TValue> is not safe to use from multiple threads at the same time. It is like a filing cabinet designed for one person. If two people try to file documents simultaneously, papers get mixed up, folders get misfiled, and the whole system breaks down.

The developer's intention was reasonable: creating UI products can be expensive (maybe it involves loading resources, reading configs, etc.), so they wanted to cache the result. The first time CreateButton() is called, it creates a WinButton and stores it in the dictionary. Every subsequent call just returns the cached button. This works perfectly in single-threaded code.

But the factory was registered as a singleton — shared across all threads. When 50 requests hit simultaneously, 50 threads all called CreateButton() at the same time. Multiple threads found the cache empty (the TryGetValue check), created new buttons, and then tried to write to the dictionary simultaneously. Dictionary is not designed for this — its internal hash buckets got corrupted, leading to race conditionsA bug where concurrent threads access shared data and the outcome depends on execution timing — one of the hardest bugs to diagnose.: infinite loops in bucket chains, lost entries, and eventually exceptions.

The bug was intermittent. In dev (one user, low traffic), it worked perfectly. In staging (moderate load), it occasionally threw a strange exception. In production (peak traffic), it crashed repeatedly. This is the hallmark of a concurrency bug — it only appears under load and is nearly impossible to reproduce on a developer's machine.

Time to Diagnose

6 hours — intermittent, only under load, dictionary corruption caused random exceptions.

// ❌ Non-thread-safe cache in singleton factory
public sealed class CachedUIFactory : IUIFactory
{
    private readonly Dictionary<string, IButton> _cache = new(); // ❌

    public IButton CreateButton()
    {
        if (!_cache.TryGetValue("btn", out var btn))
        {
            btn = new WinButton();
            _cache["btn"] = btn; // ❌ Race condition under concurrent access
        }
        return btn;
    }
}

// ✅ Use ConcurrentDictionary or FrozenDictionary
public sealed class CachedUIFactory : IUIFactory
{
    private readonly ConcurrentDictionary<string, IButton> _cache = new();

    public IButton CreateButton() =>
        _cache.GetOrAdd("btn", _ => new WinButton()); // ✅ Thread-safe

    // ✅ Or pre-build the cache at startup with FrozenDictionary
    private static readonly FrozenDictionary<string, Func<IButton>> _factories =
        new Dictionary<string, Func<IButton>>
        {
            ["win"] = () => new WinButton(),
            ["mac"] = () => new MacButton()
        }.ToFrozenDictionary();
}

Ensure all products from one factory are from the same family. Catch the "mixed families" bug at test time.

[TheoryAn xUnit test attribute that runs the same test method with different input data — each [InlineData] or [MemberData] becomes a separate test case.]
[InlineData(typeof(WinFactory), "Win")]
[InlineData(typeof(MacFactory), "Mac")]
public void Factory_Creates_Consistent_Family(Type factoryType, string prefix)
{
    var factory = (IUIFactory)Activator.CreateInstance(factoryType)!;

    var button = factory.CreateButton();
    var checkbox = factory.CreateCheckbox();

    // All products should be from the same family
    Assert.StartsWith(prefix, button.GetType().Name);
    Assert.StartsWith(prefix, checkbox.GetType().Name);
}

[Fact]
public void All_Factories_Create_NonNull_Products()
{
    var factories = typeof(IUIFactory).Assembly.GetTypes()
        .Where(t => typeof(IUIFactory).IsAssignableFrom(t)
            && t.IsClass && !t.IsAbstract);

    foreach (var type in factories)
    {
        var factory = (IUIFactory)Activator.CreateInstance(type)!;
        Assert.NotNull(factory.CreateButton());
        Assert.NotNull(factory.CreateCheckbox());
    }
}

Verify that keyed services resolve correctly and the container is wired up properly.

[Fact]
public void DI_Resolves_Correct_Factory_By_Key()
{
    var services = new ServiceCollection();
    services.AddKeyedSingleton<IUIFactory, WinFactory>("windows");
    services.AddKeyedSingleton<IUIFactory, MacFactory>("mac");
    var sp = services.BuildServiceProvider();

    var win = sp.GetRequiredKeyedService<IUIFactory>("windows");
    var mac = sp.GetRequiredKeyedService<IUIFactory>("mac");

    Assert.IsType<WinFactory>(win);
    Assert.IsType<MacFactory>(mac);
    Assert.IsType<WinButton>(win.CreateButton());
    Assert.IsType<MacButton>(mac.CreateButton());
}

Override the production factory with a test factory in integration tests to control the entire product family.

public class UITests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public UITests(WebApplicationFactory<Program> factory)
    {
        _client = factory.WithWebHostBuilder(builder =>
        {
            builder.ConfigureServices(services =>
            {
                // ✅ Replace production factory with test factory
                services.RemoveAll<IUIFactory>();
                services.AddSingleton<IUIFactory, FakeUIFactory>();
            });
        }).CreateClient();
    }

    [Fact]
    public async Task Dialog_Endpoint_Uses_Test_Factory()
    {
        var response = await _client.GetStringAsync("/dialog");
        Assert.Contains("fake-btn", response);
    }
}

For applications that need to swap factories without restarting (e.g., feature flags, A/B testing), use a factory proxy that delegates to the current active factory.

// Proxy factory that can swap the underlying implementation at runtime
public sealed class HotSwapFactory : IUIFactory
{
    private volatile IUIFactory _current;

    public HotSwapFactory(IUIFactory initial) => _current = initial;

    public IButton CreateButton() => _current.CreateButton();
    public ICheckbox CreateCheckbox() => _current.CreateCheckbox();

    // Call this from an admin endpoint or feature flag callback
    public void SwapTo(IUIFactory newFactory) => _current = newFactory;
}

// Registration
builder.Services.AddSingleton<HotSwapFactory>(sp =>
    new HotSwapFactory(sp.GetRequiredKeyedService<IUIFactory>("default")));
builder.Services.AddSingleton<IUIFactory>(sp =>
    sp.GetRequiredService<HotSwapFactory>());

// Admin endpoint to swap
app.MapPost("/admin/swap-theme/{key}", (string key, HotSwapFactory proxy, IServiceProvider sp) =>
{
    var newFactory = sp.GetRequiredKeyedService<IUIFactory>(key);
    proxy.SwapTo(newFactory);
    return Results.Ok($"Swapped to {key}");
});

Create an interface for each product type and a factory interface with one create method per product. Keep the interfaces minimal — only methods the client actually calls.

// Product interfaces — extracted from concrete types
public interface IDbConnection
{
    void Open();
    void Close();
}
public interface IDbCommand
{
    string Execute(string sql);
}

// Factory interface — one create method per product
public interface IDbFactory
{
    IDbConnection CreateConnection();
    IDbCommand CreateCommand();
}

One sealed class per switch case. Move the creation logic from each switch branch into the corresponding factory's create method. Use the Strangler Fig pattern — migrate one family at a time while the old switch handles the remaining cases.

// One factory per former switch case
public sealed class SqlServerFactory : IDbFactory
{
    public IDbConnection CreateConnection()
        => new SqlServerConnection("Server=.;Database=App;");
    public IDbCommand CreateCommand()
        => new SqlServerCommand();
}

public sealed class PostgresFactory : IDbFactory
{
    public IDbConnection CreateConnection()
        => new PostgresConnection("Host=localhost;Database=App;");
    public IDbCommand CreateCommand()
        => new PostgresCommand();
}

Register all factories with keyed services. Replace callers: inject IFactory instead of calling the switch method. Once all callers are migrated, delete the original switch class. Run tests to verify no regressions.

// Before: switch-based (delete this after migration)
IConnection conn = provider switch {
    "sql" => new SqlConn(), "pg" => new PgConn(), ...
};

// After: DI-based
public class Service(IDbFactory factory) // ✅ Injected
{
    public void Run() => factory.CreateConnection().Open();
}

// Registration
builder.Services.AddKeyedSingleton<IDbFactory, SqlFactory>("sql");
builder.Services.AddKeyedSingleton<IDbFactory, PgFactory>("pg");