Design Patterns Mastery
Lesson 5 of 30 17% of course

Factory Method: Abstracting complex object creation

15 · 8 min · 5/23/2026

Sign in to track progress and bookmarks.

Factory Method Pattern

The Factory Method pattern defines an interface for creating an object, but let subclasses decide which class to instantiate. It allows a class to defer instantiation to subclasses, keeping your high-level business logic completely decpule from "which specific object" is being used.

1. Why not just use "new"?

If you write var logger = new SQLServerLogger(); in 500 files, and next month the client wants AzureBlobLogger, you have to edit 500 files. A Factory solves this.

public abstract class LoggerFactory 
{
    // The Factory Method
    public abstract ILogger CreateLogger();
}

public class CloudLoggerFactory : LoggerFactory 
{
    public override ILogger CreateLogger() => new AzureBlobLogger();
}

2. Real-World .NET Example: IHttpClientFactory

In ASP.NET Core, you never instantiate new HttpClient(). You use a Factory. Why? Because raw HttpClients leak sockets. The Factory manages the underlying pooling and lifecycle of "Handlers" automatically, ensuring your server doesn't crash under high load.

4. Interview Mastery

Q: "When is the Factory Method better than simple Dependency Injection?"

Architect Answer: "Standard DI is great for 'Static' dependencies that exist for the whole request. You use a Factory when you need **Dynamic** creation. For example, if you need to create a new 'ProcessingTask' object every time a user clicks a button, you can't inject that task into the constructor (because it doesn't exist yet). You inject a `ITaskFactory`, and call `.Create()` at the exact millisecond the user clicks."

Test your knowledge

Quizzes linked to this course—pass to earn certificates.

Browse all quizzes
Design Patterns Mastery

On this page

1. Why not just use "new"? 2. Real-World .NET Example: IHttpClientFactory 4. Interview Mastery
1. Introduction to Design Patterns
Introduction to GoF Patterns: Why patterns matter? SOLID Principles: The foundation of all patterns DRY, KISS, and YAGNI (Architectural Philosophy)
2. Creational Patterns
Singleton Pattern: Thread-safety & Captive Dependencies Factory Method: Abstracting complex object creation Abstract Factory: Creating families of related objects Builder Pattern: Constructing complex fluents Prototype Pattern: Cloning high-cost objects
3. Structural Patterns
Adapter Pattern: Bridging incompatible interfaces Bridge Pattern: Decoupling abstraction from implementation Composite Pattern: Managing tree structures & hierarchies Decorator Pattern: Enhancing behavior without inheritance Facade Pattern: Simplifying complex library subsystems Flyweight Pattern: Drastically reducing memory footprint Proxy Pattern: Interception, Lazy-Loading, and Security
4. Behavioral Patterns
Chain of Responsibility: Middleware & Pipeline Architecture Command Pattern: Implementing Undo/Redo & Queueing Interpreter Pattern: Building domain-specific languages Iterator Pattern: Unified traversal of collections Mediator Pattern: Decoupling components with MediatR Memento Pattern: Capturing and restoring object state Observer Pattern: Pub/Sub & Event-driven architecture State Pattern: Managing complex object lifecycles Strategy Pattern: Swappable algorithms at runtime Template Method: Defining skeleton algorithms Visitor Pattern: Separating operations from data structures
5. Modern Enterprise & Cloud Patterns
Repository & Unit of Work (The EF Core Standard) CQRS Pattern (Command Query Responsibility Segregation) Circuit Breaker & Retry Patterns (Resilience with Polly) Dependency Injection Pattern (The Modern King)