Creational Design Patterns

Every program is full of the word new. It looks harmless, but every new ConcreteClass() hard-wires your code to one specific class — a decision you can never take back without editing that line. Creational patterns are five different ways to take the new out of your business logic, so a system becomes independent of how, which, who, and when its objects are created. Everything here is in C#; the lecture slides use Python, and we call out where the two languages genuinely differ.

Why creating objects is a design problem

When you write var truck = new Truck(); you have quietly made three commitments that are easy to miss:

• Which concrete class exists (Truck) — not an interface, the real class.
• How it is built — which constructor, which arguments, in which order.
• Where that knowledge lives — right here, in the middle of your business logic.

That is tight coupling: your code now depends on a concrete type. The moment a second type shows up (a Ship, a Mac button, a crypto payment) you have to reopen and edit working code — which is exactly what the Open/Closed Principle tells you not to do, and it drags in dependencies the Dependency Inversion Principle says should point at abstractions, not concretions.

The five patterns are five answers to five different creation questions:

Factory Method creational · class pattern

Intent: define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to its subclasses.

The problem: a logistics app welded to Truck

You build RoadRabbit, a logistics app. Version 1 only moves goods by truck, so the code is full of new Truck(). Then the company acquires a shipping firm and you must add ships. Here is where all that new comes back to bite you:

public class LogisticsApp
{
    public void PlanDelivery(string transportType)
    {
        ITransport transport;

        // The pain point: every new vehicle forces an edit HERE.
        if (transportType == "truck")      transport = new Truck();
        else if (transportType == "ship")  transport = new Ship();
        else throw new ArgumentException("Unknown transport");

        transport.Deliver();   // the actual work
    }
}

public abstract class Logistics
{
    // THE FACTORY METHOD — subclasses fill this in.
    public abstract ITransport CreateTransport();

    // Business logic that USES the product,
    // with zero knowledge of its concrete class.
    public void PlanDelivery()
    {
        ITransport transport = CreateTransport();
        transport.Deliver();
    }
}

The solution: delegate the new to a subclass

The insight in one sentence: replace the direct new Truck() call with a call to an overridable factory method, and let each subclass answer "which product?" The object is still built with new — but that new now lives inside CreateTransport(), where it can be overridden. The things a factory method returns are called products.

Why an abstract class for Logistics rather than an interface? Since C# 8 an interface can carry a default method body, so PlanDelivery could technically live there — but an interface still can't hold instance state or fields, and shared stateful logic belongs in an abstract class. So the design choice stands: when there's common behaviour and state to share, reach for an abstract class; when there's only a contract, an interface. (In Python this whole thing was one ABC with an @abstractmethod.)

// All products share ONE interface. The creator's factory method
// returns THIS type, so no client ever names a concrete class.
public interface ITransport
{
    void Deliver();
}

public class Truck : ITransport
{
    public void Deliver() => Console.WriteLine("Delivering by land in a box.");
}

public class Ship : ITransport
{
    public void Deliver() => Console.WriteLine("Delivering by sea in a container.");
}

public abstract class Logistics
{
    // The factory method: declared, not implemented.
    // Return type is the INTERFACE, not a concrete class.
    public abstract ITransport CreateTransport();

    // Shared business logic. Notice it calls CreateTransport()
    // without knowing (or caring) what it returns.
    public void PlanDelivery()
    {
        ITransport transport = CreateTransport();
        transport.Deliver();
    }
}

public class RoadLogistics : Logistics
{
    public override ITransport CreateTransport() => new Truck();
}

public class SeaLogistics : Logistics
{
    public override ITransport CreateTransport() => new Ship();
}

static void Run(Logistics company)
{
    // The client treats every company the same way.
    // It never writes "new Truck" or checks a type.
    company.PlanDelivery();
}

Run(new RoadLogistics());   // Delivering by land in a box.
Run(new SeaLogistics());    // Delivering by sea in a container.

public static class TransportFactory
{
    public static ITransport Create(string kind) => kind switch
    {
        "truck" => new Truck(),
        "ship"  => new Ship(),
        _ => throw new ArgumentException(nameof(kind))
    };
}

When to use it (applicability, from the slides):

• A class can't anticipate the class of objects it must create.
• A class wants its subclasses to specify the objects it creates.
• You want to localise the knowledge of which helper subclass is the delegate.

The cost: you may need a whole parallel hierarchy of creators just to introduce one product. If the choice is trivial, a Simple Factory or plain constructor is lighter. Don't build subclasses you don't need.

Abstract Factory creational · object pattern

Intent: provide an interface for creating families of related or dependent objects without specifying their concrete classes. Think of it as "Factory Method, one level up" — a factory that produces not one product but a matched set.

The problem: a cross-platform UI that keeps mixing families

You're building a UI toolkit that must run on Windows and macOS, with two widgets: Button and Checkbox. Without a pattern you check the OS every place you build a widget — and sooner or later two checks disagree:

string os = "Windows";

// In the login screen…
IButton btn = os == "Windows" ? new WinButton() : new MacButton();
ICheckbox chk = os == "Windows" ? new WinCheckbox() : new MacCheckbox();

// …later, in a totally different file (settings page):
IButton settingsBtn = os == "Windows" ? new WinButton() : new MacButton();
// Oops — a developer forgets the check here:
ICheckbox settingsChk = new MacCheckbox();   // Windows button + Mac checkbox = Frankenstein UI

The solution: one factory object that makes the whole family

The insight in one sentence: put all the "create X" methods behind a single factory interface, then write one concrete factory per family — so choosing a family is a single decision made once, and mixing becomes impossible by construction. The client receives a factory and asks it for widgets; it never sees a concrete class and never checks the OS again.

// Each PRODUCT in the family has its own interface.
public interface IButton   { void Render(); }
public interface ICheckbox { void Render(); }

// --- Windows family ---
public class WinButton   : IButton   { public void Render() => Console.WriteLine("[Win] square button"); }
public class WinCheckbox : ICheckbox { public void Render() => Console.WriteLine("[Win] checkbox"); }

// --- macOS family ---
public class MacButton   : IButton   { public void Render() => Console.WriteLine("[Mac] rounded button"); }
public class MacCheckbox : ICheckbox { public void Render() => Console.WriteLine("[Mac] checkbox"); }

// One creation method per product in the family.
// A factory MUST supply the whole set — that's the contract.
public interface IGuiFactory
{
    IButton   CreateButton();
    ICheckbox CreateCheckbox();
}

public class WindowsFactory : IGuiFactory
{
    public IButton   CreateButton()   => new WinButton();
    public ICheckbox CreateCheckbox() => new WinCheckbox();
}

public class MacFactory : IGuiFactory
{
    public IButton   CreateButton()   => new MacButton();
    public ICheckbox CreateCheckbox() => new MacCheckbox();
}

public class Application
{
    private readonly IButton _button;
    private readonly ICheckbox _checkbox;

    // The app gets a factory and NEVER checks the OS again.
    public Application(IGuiFactory factory)
    {
        _button   = factory.CreateButton();
        _checkbox = factory.CreateCheckbox();   // guaranteed same family
    }

    public void Render() { _button.Render(); _checkbox.Render(); }
}

// The ONE place the OS is checked — at startup:
IGuiFactory factory = os == "Windows" ? new WindowsFactory() : new MacFactory();
new Application(factory).Render();

When to use it (applicability, from the slides):

• A system should be independent of how its products are created, composed and represented.
• A system must be configured with one of several families of products.
• A family of related products is designed to be used together and you must enforce that.
• You ship a library and want to reveal only interfaces, not implementations.

Builder creational · object pattern

Intent: separate the construction of a complex object from its representation, so the same construction process can create different representations. In plain terms: build a big object step by step, calling only the steps you need.

The problem: the telescoping constructor

You run a custom-PC shop. A Computer has a CPU, RAM, storage, GPU, cooling, case, power supply, RGB… Trying to cover every configuration in one constructor gives you the telescoping constructor anti-pattern:

public class Computer
{
    public Computer(string cpu, string ram, string storage, string gpu,
                    string cooling, string @case, string psu,
                    bool rgb, bool wifi) { /* assign 9 fields */ }
}

// The call site is unreadable. What is 'true, false' here?
var pc = new Computer("i9", "32GB", "1TB SSD", "RTX 4090",
                      "Air", "Tower", "850W", true, false);

The solution: extract construction into a Builder (+ optional Director)

The insight in one sentence: move the construction code out of the product into a separate builder object that exposes one method per step, and let the caller run only the steps it needs. The four roles:

1. Product — the complex object (Computer). It loses its giant constructor.
2. Builder — declares the construction steps (SetCpu, SetGpu…).
3. Concrete Builder — implements those steps and holds the part being assembled (GamingPcBuilder).
4. Director (optional) — knows recipes: fixed sequences of steps you want to reuse.

// No giant constructor. Parts are added one at a time.
public class Computer
{
    private readonly List<string> _parts = new();
    public void Add(string part) => _parts.Add(part);
    public override string ToString() => string.Join(", ", _parts);
}

// Returning the builder itself (IComputerBuilder) enables
// fluent method chaining: builder.SetCpu(..).SetRam(..).
public interface IComputerBuilder
{
    IComputerBuilder Reset();
    IComputerBuilder SetCpu(string cpu);
    IComputerBuilder SetRam(string ram);
    IComputerBuilder SetGpu(string gpu);
    Computer GetResult();
}

public class GamingPcBuilder : IComputerBuilder
{
    private Computer _pc = new();

    public IComputerBuilder Reset()            { _pc = new Computer(); return this; }
    public IComputerBuilder SetCpu(string cpu) { _pc.Add($"CPU: {cpu}");  return this; }
    public IComputerBuilder SetRam(string ram) { _pc.Add($"RAM: {ram}");  return this; }
    public IComputerBuilder SetGpu(string gpu) { _pc.Add($"GPU: {gpu}");  return this; }

    public Computer GetResult()
    {
        Computer built = _pc;
        Reset();            // ready for the next build
        return built;
    }
}

// The Director knows the ORDER of steps for common builds.
// It is optional — the client can call steps directly.
public class Director
{
    public Computer BuildGamingRig(IComputerBuilder b) =>
        b.Reset().SetCpu("Intel i9").SetRam("32GB DDR5").SetGpu("RTX 4090").GetResult();

    public Computer BuildOfficePc(IComputerBuilder b) =>
        b.Reset().SetCpu("Intel i5").SetRam("16GB").GetResult();  // no GPU step
}

var director = new Director();
var builder  = new GamingPcBuilder();

Computer rig    = director.BuildGamingRig(builder);
Computer office = director.BuildOfficePc(builder);

// Or skip the Director and build a custom machine directly:
Computer custom = builder.Reset().SetCpu("Ryzen 7").SetGpu("RTX 4070").GetResult();

Console.WriteLine(rig);      // CPU: Intel i9, RAM: 32GB DDR5, GPU: RTX 4090
Console.WriteLine(office);   // CPU: Intel i5, RAM: 16GB

public class Computer
{
    public string Cpu { get; init; } = "";
    public string Ram { get; init; } = "";
    public string? Gpu { get; init; }           // optional
}

// Named, order-free, optional — no telescoping constructor needed:
var pc = new Computer { Cpu = "i9", Ram = "32GB", Gpu = "RTX 4090" };

public record NetworkRequest(string Url, string? Auth = null, int Cache = 0);

var baseReq = new NetworkRequest("google.com");
var authed  = baseReq with { Auth = "abc123", Cache = 60000 };  // non-destructive copy

When to use it (applicability, from the slides):

• The algorithm for creating a complex object should be independent of the parts and how they're assembled.
• The construction process must allow different representations of the constructed object.

The cost: more moving parts (a builder class per representation, maybe a director). Overkill for objects with two or three fields — use a constructor or an object initializer there.

Prototype creational · object pattern · aka Clone

Intent: specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. In short: build a new object by cloning an existing one, without your code knowing its concrete class.

The problem: copying an object from the outside

Say you want an exact copy of an existing configured object. Doing it "by hand" from outside is surprisingly broken:

// You want a duplicate of 'original'…
var copy = new Character();
copy.Name  = original.Name;
copy.Level = original.Level;
copy.Home  = original.Home;      // and you must KNOW every field
// copy.Secret = original.Secret; // …but private fields aren't visible from here!

The solution: let the object clone itself

The insight in one sentence: declare a common Clone() method and let each class copy itself — it can see its own private fields, and callers never name the concrete type. In C# the base object.MemberwiseClone() does the field-copy for you. But that is exactly where the famous trap lives:

public class Address { public string City = ""; }

public class Character
{
    public string Name = "";
    public Address Home = new();

    // Shallow: Home reference is COPIED, not the Address itself.
    public Character ShallowClone() => (Character)MemberwiseClone();
}

var c2 = c1.ShallowClone();
c2.Home.City = "Kandy";   // ⚠️ also changes c1.Home.City —
                          // both point at the SAME Address!

public class Character
{
    public string Name = "";
    public Address Home = new();

    public Character DeepClone()
    {
        var copy = (Character)MemberwiseClone();   // top-level fields
        copy.Home = new Address { City = Home.City }; // clone the nested one
        return copy;
    }
}

var c2 = c1.DeepClone();
c2.Home.City = "Kandy";   // ✅ c1.Home.City is untouched —
                          // c2 has its OWN Address.

public class ShapeRegistry
{
    private readonly Dictionary<string, Shape> _prototypes = new();
    public void Register(string key, Shape p) => _prototypes[key] = p;
    public Shape Get(string key) => _prototypes[key].Clone();   // returns a COPY
}

When to use it: when your classes to instantiate are specified at runtime; when creating an object is costly (e.g. it required a big DB query) and copying a ready one is cheaper; or when objects have dozens of fields and hundreds of configurations — cloning a configured prototype beats subclassing for every combination. The cost: cloning objects with circular references or deep graphs is fiddly, and every class must implement its own correct deep clone.

Singleton creational · object pattern

Intent: ensure a class has exactly one instance, and provide a global point of access to it. Common uses from the slides: a network manager, database access, logging, utility classes.

The solution: private constructor + static accessor

The insight in one sentence: make the constructor private so nobody outside can call new, and expose a single static accessor that creates the instance once and returns the cached one thereafter. Two mandatory steps, every time:

1. Make the default constructor private — blocks new Logger() from anywhere else.
2. Add a static creation method/property that lazily creates and caches the sole instance.

public sealed class Logger
{
    private static Logger? _instance;
    private Logger() { }   // step 1: block external 'new'

    public static Logger Instance
    {
        get
        {
            // step 2 — but this check-then-create is a RACE:
            if (_instance == null)      // two threads can BOTH see null…
                _instance = new Logger(); // …and BOTH create an instance.
            return _instance;
        }
    }
}

public sealed class Logger
{
    // Lazy<T> is thread-safe by default and creates
    // the value only on first access.
    private static readonly Lazy<Logger> _lazy =
        new(() => new Logger());

    private Logger() { }

    public static Logger Instance => _lazy.Value;
}

private static Logger? _instance;
private static readonly object _gate = new();
public static Logger Instance
{
    get { lock (_gate) { return _instance ??= new Logger(); } }
}

private static volatile Logger? _instance;   // 'volatile' matters here
public static Logger Instance
{
    get
    {
        if (_instance == null)               // fast path, no lock
            lock (_gate)
                if (_instance == null)        // re-check inside the lock
                    _instance = new Logger();
        return _instance;
    }
}

public sealed class Logger
{
    public static readonly Logger Instance = new();
    private Logger() { }
}

// ASP.NET Core: one instance for the whole app, but injected, not global.
services.AddSingleton<ILogger, Logger>();

public class OrderService
{
    private readonly ILogger _log;
    public OrderService(ILogger log) => _log = log;  // dependency is VISIBLE and swappable
}

When to use it (applicability, from the slides): when there must be exactly one instance available to all clients (e.g. one shared database object), and when you need stricter control than a global variable — unlike a global, the Singleton guarantees nothing can replace the cached instance. Even so, prefer DI's singleton lifetime for anything testable.

Choosing: which creational pattern?

All five take the new out of your business logic — the question is which creation problem you have. Answer the questions in the tree, or use the interactive chooser below.

The five, side by side

Check yourself — chapter quiz