Null Object

The three participants

The pattern is tiny — an interface and two kinds of implementation of it:

• The abstract type — the interface callers program against: Customer (with getPlan()) and Plan (with getDiscount(), perks()). Callers only ever see this type, never a concrete class.
• Real implementations — the objects with actual behaviour: a MemberCustomer whose GoldPlan returns 20% off and real perks.
• The Null implementation — GuestCustomer and NoDiscountPlan: same interface, neutral behaviour. Numbers return 0, collections return empty (never null), actions are no-ops. It does nothing — safely.

Because a null object holds no state and always behaves the same, you usually create one shared instance and hand it out everywhere — a natural little [[singleton]]. There's no point allocating a fresh NoDiscountPlan per walk-in when every one of them is identical.

interface Plan {
  getDiscount(): number;                 // percent off
}

class GoldPlan implements Plan {
  getDiscount() { return 20; }           // real behaviour
}

class NoDiscountPlan implements Plan {   // the Null Object
  static readonly INSTANCE = new NoDiscountPlan();  // stateless → share one
  getDiscount() { return 0; }            // neutral: safely does nothing
}

// lookupCustomer() NEVER returns null — walk-ins get a GuestCustomer
// whose getPlan() is NoDiscountPlan.INSTANCE. So checkout is one line:
const price = 10 * (1 - shop.lookupCustomer(card).getPlan().getDiscount() / 100);

Where it shines

• Chained calls — a().b().c() is only safe if no link can be null. Null objects keep the whole chain alive with neutral values, exactly like the checkout line above.
• Collections mixing real and 'missing' entries — loop over customers and call getPlan().getDiscount() on every element without filtering; guests simply contribute 0.
• Default collaborators — give a class a NullLogger by default so its code calls logger.log(...) unconditionally; wire in a real logger only when you want output.

The honest caveat: it can hide real errors

A null object swallows absence. That's the feature — and the danger. If 'missing' is a genuine error the caller must know about (an unknown payment account, a required config key), a silent do-nothing object turns a loud crash into a quiet wrong answer that surfaces days later. Reserve the pattern for cases where doing nothing is correct, not merely convenient.

You've already met this pattern in the wild: a NullLogger (log calls go nowhere), the guest user/session every web framework hands to signed-out visitors, a no-op cache used when caching is disabled, and the empty iterator — the reason for (x of emptyList) just runs zero times instead of crashing.

Use it when doing nothing is the correct answer

• A sane do-nothing default exists — 0% discount, empty perks, a log call that goes nowhere. If the neutral behaviour is genuinely right for the missing case, a null object encodes it once.
• Callers shouldn't care about absence — checkout should not branch on 'is this a member?'; it should just ask the plan for a discount and get 0 for guests.
• Chained calls and collection loops — anywhere null would force a guard before every dot or a filter before every loop.
• Optional collaborators — loggers, metrics, caches, notifiers that a class should be able to call unconditionally whether or not one is configured.

Skip it when absence is an error

• The caller must know something is missing — an unknown payment account, a required config key, a failed lookup that should stop the flow. A silent no-op here converts a loud, debuggable crash into quiet wrong behaviour.
• Different callers need different reactions to absence — one wants a retry, one wants an error page. A null object bakes in a single reaction (nothing); prefer Optional/Maybe types or explicit | undefined handling so each caller decides.
• You'd need the null object to lie — if GuestCustomer had to fake a name, an ID, and an address to satisfy the interface, the 'neutral' behaviour isn't neutral anymore. That's a sign the design wants explicit absence.