Creational patterns

A design pattern is a named, reusable solution to a problem that keeps recurring. It is not code to paste. It is a shape of solution with known tradeoffs, and a shared word that lets a team say much in a few syllables. Creational patterns deal with one recurring problem: object creation.

The problem is that new CarRule() ties the caller to one concrete class. If the choice changes, every place that wrote new changes with it.

A factory is a function or method that decides which class to create and returns it behind an interface.

function ruleFor(kind: "car" | "bike" | "truck"): PricingRule {
  switch (kind) {
    case "car": return new CarRule();
    case "bike": return new BikeRule();
    case "truck": return new TruckRule();
  }
}

Callers ask for a rule and never name a class. The one switch now lives in one place. In the factory method form, a base class declares the creating method and subclasses decide the product.

When several related objects must match, such as pricing and receipts for one region, an abstract factory creates the whole family.

interface RegionKit { rule(): PricingRule; receipt(): ReceiptPrinter }
class IndiaKit implements RegionKit { /* rupee rules, GST receipt */ }
class UsKit implements RegionKit { /* dollar rules, tax receipt */ }

Swap the kit and everything switches together, so mismatched parts cannot be combined. The cost is many small classes and a heavier change when you add a new product type to the family.

When an object has many optional settings, a constructor with eight parameters is unreadable and easy to misorder. A builder sets them by name and creates the finished object last.

const lot = new LotBuilder()
  .floors(3)
  .slotsPerFloor(40)
  .rule(new CarRule())
  .build();

The builder can also check that the combination is valid before creating anything, so you never hold a half built object.

A singleton guarantees one instance and a global way to reach it.

class Config {
  private static instance?: Config;
  private constructor() {}
  static get(): Config { return (Config.instance ??= new Config()); }
}

Use it sparingly. It is global state in disguise, so any code can reach it, tests leak into each other, and dependencies become invisible. Often you only need one instance, not a global door. Create one object at startup and pass it in, which keeps the benefit without the cost.

When creating from scratch is costly or fiddly, prototype makes new objects by cloning a configured one.

const holiday = structuredClone(baseRuleSet);
holiday.hourly = 30;

It suits objects with heavy setup or when you want variations of a template. Beware shallow copies that share inner objects.

Reach for a factory when callers should not name classes, an abstract factory when parts must match, a builder when construction is complicated, and a prototype when cloning is cheaper. Treat singleton as a last resort. Do not add any of them until the plain new actually hurts.