Factory Method: The Restaurant Kitchen Pattern

When I first read about the Factory Method pattern, every explanation sounded like this: "Define an interface for creating an object, but let subclasses decide which class to instantiate."

I read that sentence five times and understood nothing. So here's the explanation I wish someone had given me.

Order the biryani. Don't cook it.

You walk into a restaurant and say: "One biryani please."

You do NOT walk into the kitchen, pick up the rice, light the stove, and cook it yourself. The kitchen does that. You say what you want, and the kitchen decides how to make it and hands it over.

That's the entire Factory Method pattern:

• 
  You = your code that needs an object


• 
  The kitchen = the factory


• 
  The biryani = the object you get back

The code version

Let's say your app sends notifications — email, Teams, or SMS.

Without a factory, every file that sends a notification cooks its own meal:

// This if-else gets copy-pasted in 20 different files 😫

INotificationSender sender;

if (type == "email") sender = new EmailSender();

else if (type == "teams") sender = new TeamsSender();

else sender = new SmsSender();



sender.Send("Hello!");

With a factory, those 20 files just place an order:

var sender = NotificationFactory.Create(type);

sender.Send("Hello!");

Wait... what's inside Create()?

Here's the secret nobody tells beginners: nothing magical.

public static class NotificationFactory

{

    public static INotificationSender Create(string type)

    {

        if (type == "email") return new EmailSender();   // just new!

        if (type == "teams") return new TeamsSender();   // just new!

        if (type == "sms")   return new SmsSender();     // just new!

        throw new ArgumentException("Unknown type");

    }

}

It's an if-else with new inside. That's it.

The pattern was never about avoiding new — someone always has to create the object. The pattern is about WHERE the new lives. The restaurant didn't eliminate cooking; it just made sure cooking happens in one room instead of every customer cooking at their own table.

The three ingredients

Many classes         →  EmailSender, TeamsSender, SmsSender   (the chefs)

One common interface →  INotificationSender                   (the menu)

One factory class    →  NotificationFactory                   (the kitchen)

The interface matters more than it looks. Because the factory returns INotificationSender, the caller genuinely doesn't know which class it received — it just knows "whatever this is, it has a .Send() method." Every dish on the menu can be eaten with the same spoon.

public interface INotificationSender

{

    void Send(string message);

}



public class EmailSender : INotificationSender

{

    public void Send(string message) { /* SMTP call */ }

}



public class TeamsSender : INotificationSender

{

    public void Send(string message) { /* webhook call */ }

}

Why bother? The WhatsApp test

Your boss walks in: "Add WhatsApp notifications by Friday."

Without factory: you hunt down the if-else in 20 files and edit each one. Miss one → production bug.

With factory: you write one WhatsAppSender class and add one line to the factory. The 20 caller files don't change. They don't even know anything happened.

That's the whole payoff: when things change, you touch one place instead of everywhere.

One line to remember

Factory Method = don't cook it yourself, just order it.

Many small classes, one shared interface, and one kitchen where all the new happens.

This is part 2 of a series on must-know design patterns in C#, explained the simple way. Part 1 covered Singleton. Next up: Builder — the Subway sandwich pattern.