Abstract Factory vs Factory Method Pattern in C#: Key Differences Explained

Understanding the difference between Abstract Factory and Factory Method patterns is crucial for C# developers. Both are creational design patterns, but they solve different problems and are used in different scenarios. Knowing when to use each pattern will help you write better, more maintainable code.

The confusion between these patterns is common because they have similar names and both deal with object creation. However, Abstract Factory creates families of related objects, while Factory Method creates single objects. This fundamental difference affects when and how you use each pattern.

In this article, we'll explore both patterns side-by-side with practical C# examples, clear comparisons, and guidance to help you choose the right pattern for your situation.

This article focuses on: Pattern differentiation and migration guidance between Abstract Factory and Factory Method. We assume familiarity with Abstract Factory basics—for foundational concepts, see Abstract Factory Design Pattern: Complete Guide. For decision-making guidance on when to use Abstract Factory specifically, see When to Use Abstract Factory Pattern. For implementation details, see How to Implement Abstract Factory Pattern.

For a comprehensive overview of design patterns, see The Big List of Design Patterns.

Understanding Factory Method Pattern

Factory Method is a creational pattern that provides an interface for creating objects but lets subclasses decide which class to instantiate. It uses inheritance to delegate object creation to subclasses.

Factory Method Structure

The Factory Method pattern follows a specific structure that separates product creation from product usage. This structure allows subclasses to determine which concrete product to instantiate while keeping the client code decoupled from specific implementations.

// Product interface
public interface ILogger
{
    void Log(string message);
}

// Concrete products
public class FileLogger : ILogger
{
    public void Log(string message)
    {
        File.AppendAllText("log.txt", $"{DateTime.Now}: {message}\n");
    }
}

public class ConsoleLogger : ILogger
{
    public void Log(string message)
    {
        Console.WriteLine($"{DateTime.Now}: {message}");
    }
}

// Creator (abstract class with factory method)
public abstract class LoggerFactory
{
    // Factory Method - subclasses implement this
    public abstract ILogger CreateLogger();
    
    // Template method using the factory method
    public void LogMessage(string message)
    {
        var logger = CreateLogger();
        logger.Log(message);
    }
}

// Concrete creators
public class FileLoggerFactory : LoggerFactory
{
    public override ILogger CreateLogger() => new FileLogger();
}

public class ConsoleLoggerFactory : LoggerFactory
{
    public override ILogger CreateLogger() => new ConsoleLogger();
}

// Usage
var fileFactory = new FileLoggerFactory();
fileFactory.LogMessage("This goes to a file");

var consoleFactory = new ConsoleLoggerFactory();
consoleFactory.LogMessage("This goes to console");

Key Characteristics of Factory Method

Factory Method has distinct characteristics that differentiate it from Abstract Factory. Understanding these traits helps clarify when Factory Method is the appropriate choice.

1. Single Product Type: Creates one type of product (e.g., ILogger)
2. Inheritance-Based: Uses abstract classes and method overriding
3. Subclass Decision: Subclasses decide which concrete product to create
4. Simple: Easier to understand and implement than Abstract Factory

Understanding Abstract Factory Pattern

Abstract Factory creates families of related objects without specifying their concrete classes. It uses composition rather than inheritance. This pattern ensures that all objects created by a factory belong to the same family and are guaranteed to work together correctly. Unlike Factory Method, which creates single objects, Abstract Factory manages multiple related product types simultaneously.

Note: For comprehensive coverage of Abstract Factory concepts and implementation, see Abstract Factory Design Pattern: Complete Guide. This section focuses on Abstract Factory's characteristics relevant to comparison with Factory Method.

Abstract Factory Structure

// Abstract products
public interface IButton
{
    void Render();
}

public interface IDialog
{
    void Show();
}

// Concrete products for Windows
public class WindowsButton : IButton
{
    public void Render() => Console.WriteLine("Windows button rendered");
}

public class WindowsDialog : IDialog
{
    public void Show() => Console.WriteLine("Windows dialog shown");
}

// Concrete products for macOS
public class MacButton : IButton
{
    public void Render() => Console.WriteLine("macOS button rendered");
}

public class MacDialog : IDialog
{
    public void Show() => Console.WriteLine("macOS dialog shown");
}

// Abstract Factory
public interface IUIFactory
{
    IButton CreateButton();
    IDialog CreateDialog();
}

// Concrete factories
public class WindowsUIFactory : IUIFactory
{
    public IButton CreateButton() => new WindowsButton();
    public IDialog CreateDialog() => new WindowsDialog();
}

public class MacUIFactory : IUIFactory
{
    public IButton CreateButton() => new MacButton();
    public IDialog CreateDialog() => new MacDialog();
}

// Client code
public class Application
{
    private readonly IUIFactory _factory;
    
    public Application(IUIFactory factory)
    {
        _factory = factory;
    }
    
    public void BuildUI()
    {
        var button = _factory.CreateButton();
        var dialog = _factory.CreateDialog();
        // Both are guaranteed to be from the same platform
    }
}

Key Characteristics of Abstract Factory

Abstract Factory differs from Factory Method in several important ways. These characteristics make it suitable for different scenarios than Factory Method.

1. Multiple Product Types: Creates families of related products (e.g., IButton and IDialog)
2. Composition-Based: Uses interfaces and object composition
3. Family Guarantee: Ensures all products come from the same family
4. More Complex: Handles multiple related objects

Side-by-Side Comparison

Let's compare both patterns with a concrete example: creating database connections. This comparison highlights the key differences in how each pattern approaches object creation.

Factory Method Example: Single Database Connection

Factory Method is ideal when you only need to create a single type of object. In this database example, we're creating just connection objects, making Factory Method the appropriate choice.

// Factory Method - creates one product type
public abstract class DatabaseConnectionFactory
{
    public abstract IDbConnection CreateConnection();
    
    public void ExecuteQuery(string query)
    {
        using var connection = CreateConnection();
        connection.Open();
        // Execute query...
    }
}

public class SqlServerConnectionFactory : DatabaseConnectionFactory
{
    public override IDbConnection CreateConnection() 
        => new SqlConnection("Server=...");
}

public class MySqlConnectionFactory : DatabaseConnectionFactory
{
    public override IDbConnection CreateConnection() 
        => new MySqlConnection("Server=...");
}

Abstract Factory Example: Database Family

// Abstract Factory - creates family of related products
public interface IDatabaseFactory
{
    IDbConnection CreateConnection();
    IDbCommand CreateCommand();
    IDbDataAdapter CreateDataAdapter();
}

public class SqlServerFactory : IDatabaseFactory
{
    public IDbConnection CreateConnection() => new SqlConnection("Server=...");
    public IDbCommand CreateCommand() => new SqlCommand();
    public IDbDataAdapter CreateDataAdapter() => new SqlDataAdapter();
}

public class MySqlFactory : IDatabaseFactory
{
    public IDbConnection CreateConnection() => new MySqlConnection("Server=...");
    public IDbCommand CreateCommand() => new MySqlCommand();
    public IDbDataAdapter CreateDataAdapter() => new MySqlDataAdapter();
}

// Client ensures all database objects are compatible
public class DataAccessLayer
{
    private readonly IDatabaseFactory _factory;
    
    public DataAccessLayer(IDatabaseFactory factory)
    {
        _factory = factory;
    }
    
    public void ExecuteQuery(string query)
    {
        using var connection = _factory.CreateConnection();
        var command = _factory.CreateCommand();
        var adapter = _factory.CreateDataAdapter();
        // All objects are from the same database family
    }
}

Key Differences Summary

The following table summarizes the key differences between Factory Method and Abstract Factory patterns. This comparison helps clarify when to use each pattern.

When to Use Factory Method

Factory Method is ideal for specific scenarios. Understanding these use cases helps you choose the right pattern for your situation.

Use Factory Method when:

1. You need a single product type: You're creating one kind of object (logger, connection, etc.)
2. Subclasses should decide: You want subclasses to determine which concrete class to instantiate
3. Simple scenario: Your use case doesn't require multiple related objects
4. Framework design: You're designing a framework where clients extend creation logic

Example: Logger Factory

This example demonstrates Factory Method in a logging scenario where only a single logger type is needed. The pattern allows different subclasses to provide different logger implementations.

// Perfect for Factory Method - single product type
public abstract class LoggerFactory
{
    public abstract ILogger CreateLogger();
}

public class FileLoggerFactory : LoggerFactory
{
    public override ILogger CreateLogger() => new FileLogger();
}

When to Use Abstract Factory

Abstract Factory addresses different needs than Factory Method. These scenarios indicate when Abstract Factory is the better choice.

Use Abstract Factory when:

1. You need families of objects: Multiple related objects that must work together
2. Compatibility matters: Objects from different classes must be compatible
3. Multiple variants: You need to support different families (themes, platforms, providers)
4. Consistency required: All objects should come from the same family

Example: UI Theme Factory

// Perfect for Abstract Factory - family of related objects
public interface IThemeFactory
{
    IButton CreateButton();
    IDialog CreateDialog();
    IMenu CreateMenu();
}

public class DarkThemeFactory : IThemeFactory
{
    public IButton CreateButton() => new DarkButton();
    public IDialog CreateDialog() => new DarkDialog();
    public IMenu CreateMenu() => new DarkMenu();
}

Real-World Example: Payment Processing

Payment processing provides a practical example of when to use each pattern. The choice depends on whether you need a single payment processor or a complete payment system with multiple related components.

Factory Method: Single Payment Method

When you only need to process payments through a single method, Factory Method is sufficient. This example shows how to create different payment processors without needing related objects.

// Factory Method - one payment type
public abstract class PaymentProcessorFactory
{
    public abstract IPaymentProcessor CreateProcessor();
}

public class CreditCardProcessorFactory : PaymentProcessorFactory
{
    public override IPaymentProcessor CreateProcessor() 
        => new CreditCardProcessor();
}

Abstract Factory: Complete Payment System

// Abstract Factory - payment system family
public interface IPaymentSystemFactory
{
    IPaymentAuthorization CreateAuthorization();
    IPaymentTransfer CreateTransfer();
    IPaymentRefund CreateRefund();
}

public class CreditCardSystemFactory : IPaymentSystemFactory
{
    public IPaymentAuthorization CreateAuthorization() 
        => new CreditCardAuthorization();
    public IPaymentTransfer CreateTransfer() 
        => new CreditCardTransfer();
    public IPaymentRefund CreateRefund() 
        => new CreditCardRefund();
}

Decision Matrix

Choosing between Factory Method and Abstract Factory can be challenging. This decision matrix provides a systematic approach to selecting the right pattern based on your requirements. Note: For comprehensive decision-making guidance specifically about when to use Abstract Factory (including warning signs and detailed scenarios), see When to Use Abstract Factory Pattern.

Use this decision matrix to choose the right pattern:

Do you need multiple related objects that must work together?
├─ YES → Use Abstract Factory
└─ NO
   └─ Do you want subclasses to decide what to create?
      ├─ YES → Use Factory Method
      └─ NO → Consider Simple Factory or direct instantiation

Combining Both Patterns

You can combine both patterns effectively. For example, an Abstract Factory might use Factory Methods internally to create individual products within the family. This combination leverages the strengths of both patterns.

// Abstract Factory using Factory Method internally
public interface IUIFactory
{
    IButton CreateButton();
    IDialog CreateDialog();
}

public abstract class ThemeFactory : IUIFactory
{
    // Factory Method for button
    public abstract IButton CreateButton();
    
    // Factory Method for dialog
    public abstract IDialog CreateDialog();
    
    // Template method using factory methods
    public void CreateUI()
    {
        var button = CreateButton();
        var dialog = CreateDialog();
        // Use both...
    }
}

public class DarkThemeFactory : ThemeFactory
{
    public override IButton CreateButton() => new DarkButton();
    public override IDialog CreateDialog() => new DarkDialog();
}

Common Mistakes

Developers often confuse Factory Method and Abstract Factory, leading to common implementation mistakes. Understanding these pitfalls helps you avoid them.

Mistake 1: Using Abstract Factory for Single Objects

// Wrong: Abstract Factory for single product
public interface ILoggerFactory
{
    ILogger CreateLogger(); // Only one method - use Factory Method instead
}

Mistake 2: Using Factory Method for Object Families

Attempting to use Factory Method for creating families of related objects leads to design issues. When you need multiple related products, Abstract Factory is the correct pattern to use.

// Wrong: Factory Method trying to create families
public abstract class UIFactory
{
    public abstract IButton CreateButton();
    public abstract IDialog CreateDialog(); // This suggests Abstract Factory
}

Mistake 3: Confusing the Patterns

The key to avoiding confusion is understanding the fundamental differences between these patterns. Remember: Factory Method = inheritance + single product, Abstract Factory = composition + product families. Factory Method uses abstract classes and method overriding to let subclasses decide which single product to create. Abstract Factory uses interfaces and composition to create families of related products that must be compatible.

C# Implementation Tips

Modern C# features and best practices can enhance both Factory Method and Abstract Factory implementations. These tips help you write cleaner, more maintainable code.

Factory Method with Interfaces

In modern C#, you can use interfaces instead of abstract classes:

public interface ILoggerFactory
{
    ILogger CreateLogger();
}

public class FileLoggerFactory : ILoggerFactory
{
    public ILogger CreateLogger() => new FileLogger();
}

Abstract Factory with Dependency Injection

Abstract Factory integrates seamlessly with dependency injection containers. This approach allows you to configure which factory implementation to use at runtime, making your code more flexible and testable.

// Register factory
services.AddScoped<IUIFactory, WindowsUIFactory>();

// Use in constructor
public class Application
{
    public Application(IUIFactory factory) { }
}

Testing Considerations

Both patterns are testable, but they require slightly different testing approaches. Understanding how to test each pattern ensures your implementations work correctly.

Testing Factory Method

[Fact]
public void FileLoggerFactory_CreatesFileLogger()
{
    var factory = new FileLoggerFactory();
    var logger = factory.CreateLogger();
    
    Assert.IsType<FileLogger>(logger);
}

Testing Abstract Factory

Testing Abstract Factory requires verifying that all products created by a factory belong to the same family and are compatible. This example demonstrates testing that a Windows UI factory creates Windows-compatible products.

[Fact]
public void WindowsUIFactory_CreatesWindowsProducts()
{
    var factory = new WindowsUIFactory();
    var button = factory.CreateButton();
    var dialog = factory.CreateDialog();
    
    Assert.IsType<WindowsButton>(button);
    Assert.IsType<WindowsDialog>(dialog);
}

Conclusion

Understanding the difference between Factory Method and Abstract Factory is essential for making the right design decisions:

• Factory Method: Use when you need a single product type and want subclasses to decide creation
• Abstract Factory: Use when you need families of related objects that must be compatible

Both patterns have their place in C# development. Factory Method is simpler and perfect for single-object creation scenarios. Abstract Factory is more powerful and essential when object compatibility matters.

The key is recognizing when you need object families versus single objects. Once you understand this distinction, choosing the right pattern becomes straightforward.

For more on design patterns, explore The Big List of Design Patterns.

Frequently Asked Questions

Can I use Factory Method and Abstract Factory together?

Yes! Abstract Factory can use Factory Methods internally. For example, an Abstract Factory might have methods that use Factory Method pattern to create individual products within the family.

Which pattern is more common in C#?

Factory Method is more common for simple scenarios, but Abstract Factory is widely used in frameworks like .NET's data providers and UI frameworks where object families need to be compatible.

Is Abstract Factory just multiple Factory Methods?

Not exactly. Abstract Factory creates families of related objects, while multiple Factory Methods would create unrelated objects. The key difference is the relationship and compatibility between products.

When should I avoid Abstract Factory?

Avoid Abstract Factory when you only need single objects, when objects don't need to be related, or when the added complexity isn't justified by your requirements. Start simple with Factory Method or direct instantiation.

Can I convert Factory Method to Abstract Factory?

Yes, if you find you need multiple related products. Refactor by creating an interface with multiple creation methods and ensuring products are compatible. However, don't over-engineer—only do this if you actually need the family relationship.

How do I choose between these patterns?

Ask: "Do I need multiple related objects that must work together?" If yes → Abstract Factory. If no → Factory Method or simpler patterns. The decision matrix in this article can help guide you.

Are there performance differences?

The performance difference is negligible. Both patterns add a small indirection overhead. Choose based on design needs, not performance. The clarity and maintainability benefits far outweigh any tiny performance cost.