Factory & Builder Patterns

Creational patterns aren't just for academic theory. In .NET, the Builder is how we configure apps, and the Factory is how we handle complex object creation.

1. The Builder Pattern

Look at WebApplication.CreateBuilder(args). This is a master-class in the Builder pattern. It allows you to 'Chain' your configuration (Services, Middleware, Logging) in a logical, readable way. You should use this same pattern for your own complex domain objects.

2. The Abstract Factory

When you have 5 different Payment Providers (Stripe, Paypal, etc.) and you don't know which one you need until runtime, you use a **PaymentFactory**.

public IPaymentProvider GetProvider(string type) => type switch { ... };

This keeps your controllers clean. They only know about the interface (`IPaymentProvider`), not the concrete implementations.

4. Interview Mastery

Q: "Is the 'Factory' pattern still needed if we have DI?"

Architect Answer: "YES! DI handles 'Service' creation (what to use). The Factory handles 'Dynamic' creation (which one to use at runtime). If a user chooses 'Export to PDF' or 'Export to Excel', the DI container doesn't know which one to inject. You inject a Factory, and the Factory makes the decision based on user input. DI and Factory work together—they don't replace each other."