Design Patterns Mastery

Factory Method: Abstracting complex object creation

1 Views Updated 5/4/2026

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."

Design Patterns 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)