Null Object Pattern: Eliminate Null Checks

Tony Hoare called null references his “billion-dollar mistake.” He wasn’t exaggerating. Null checks are the most pervasive source of branching and bugs in most codebases:

function getDiscountedPrice(product: Product, coupon: Coupon | null): number {
  if (coupon !== null) {
    if (coupon.isValid()) {
      if (coupon.appliesTo(product.category)) {
        return product.price * (1 - coupon.discount);
      }
    }
  }
  return product.price;
}

Three levels of nesting to handle one concept. And this pattern repeats everywhere:

// This is in every codebase
if (user !== null) {
  if (user.preferences !== null) {
    if (user.preferences.theme !== null) {
      applyTheme(user.preferences.theme);
    }
  }
}

The Null Object pattern eliminates this by replacing null with an object that does nothing — but does it safely.

The Pattern

Instead of returning null when something doesn’t exist, return an object that implements the same interface but with neutral, do-nothing behavior:

interface Logger {
  info(message: string): void;
  error(message: string): void;
  warn(message: string): void;
}

class ConsoleLogger implements Logger {
  info(message: string): void { console.log(`[INFO] ${message}`); }
  error(message: string): void { console.error(`[ERROR] ${message}`); }
  warn(message: string): void { console.warn(`[WARN] ${message}`); }
}

// The Null Object — same interface, does nothing
class NullLogger implements Logger {
  info(_message: string): void { /* intentionally empty */ }
  error(_message: string): void { /* intentionally empty */ }
  warn(_message: string): void { /* intentionally empty */ }
}

Now consumers never need to check for null:

class OrderService {
  private logger: Logger;

  constructor(logger?: Logger) {
    this.logger = logger ?? new NullLogger(); // Never null
  }

  async processOrder(order: Order): Promise<void> {
    this.logger.info(`Processing order ${order.id}`);
    // No null check needed — NullLogger safely swallows the call
    await this.doProcessing(order);
    this.logger.info(`Order ${order.id} completed`);
  }
}

// Both work identically from the consumer's perspective:
const withLogging = new OrderService(new ConsoleLogger());
const withoutLogging = new OrderService(); // Uses NullLogger internally

Before and After: A Real Example

Here’s a notification system riddled with null checks:

Before: Null Checks Everywhere

class UserDashboard {
  private notifier: Notifier | null;
  private analytics: Analytics | null;
  private cache: Cache | null;

  constructor(
    notifier: Notifier | null,
    analytics: Analytics | null,
    cache: Cache | null,
  ) {
    this.notifier = notifier;
    this.analytics = analytics;
    this.cache = cache;
  }

  async updateProfile(userId: string, changes: ProfileChanges): Promise<void> {
    await this.saveToDatabase(userId, changes);

    if (this.cache !== null) {
      this.cache.invalidate(`user:${userId}`);
    }

    if (this.notifier !== null) {
      this.notifier.send(userId, "Your profile was updated");
    }

    if (this.analytics !== null) {
      this.analytics.track("profile_updated", { userId });
    }
  }
}

After: Null Objects

// Null Objects — each implements its interface with no-op behavior
class NullNotifier implements Notifier {
  send(_userId: string, _message: string): void { }
}

class NullAnalytics implements Analytics {
  track(_event: string, _data: Record<string, unknown>): void { }
}

class NullCache implements Cache {
  get(_key: string): unknown { return undefined; }
  set(_key: string, _value: unknown): void { }
  invalidate(_key: string): void { }
}

class UserDashboard {
  constructor(
    private notifier: Notifier = new NullNotifier(),
    private analytics: Analytics = new NullAnalytics(),
    private cache: Cache = new NullCache(),
  ) {}

  async updateProfile(userId: string, changes: ProfileChanges): Promise<void> {
    await this.saveToDatabase(userId, changes);
    this.cache.invalidate(`user:${userId}`);
    this.notifier.send(userId, "Your profile was updated");
    this.analytics.track("profile_updated", { userId });
    // No null checks. Every call is safe. The code just flows.
  }
}

The updateProfile method went from 15 lines with 3 null checks to 5 clean lines. And it’s easier to test — inject the null objects when you don’t care about those side effects.

Null Objects for Collections

The pattern works beautifully for collections. Instead of returning null for “no results,” return an empty collection:

// Bad — callers must check for null before iterating
function getActiveUsers(): User[] | null {
  const users = database.query("SELECT * FROM users WHERE active = true");
  if (users.length === 0) return null;
  return users;
}

// Every caller:
const users = getActiveUsers();
if (users !== null) {
  for (const user of users) {
    // ...
  }
}

// Good — empty array is the "null object" for collections
function getActiveUsers(): User[] {
  return database.query("SELECT * FROM users WHERE active = true");
  // Returns [] if no results — callers iterate safely
}

// Every caller — no check needed:
for (const user of getActiveUsers()) {
  // If empty, loop body never executes. Clean.
}

This is so effective that most modern APIs do it by default. If you ever find yourself returning null for “no items,” return an empty array instead.

Python Implementation

Python’s duck typing makes null objects even more natural:

from typing import Protocol

class Discount(Protocol):
    def apply(self, price: float) -> float: ...
    def description(self) -> str: ...

class PercentageDiscount:
    def __init__(self, percent: float):
        self._percent = percent

    def apply(self, price: float) -> float:
        return price * (1 - self._percent / 100)

    def description(self) -> str:
        return f"{self._percent}% off"

class NoDiscount:
    """Null Object — applies no discount."""
    def apply(self, price: float) -> float:
        return price  # Price unchanged

    def description(self) -> str:
        return "No discount applied"

def calculate_total(items: list[Item], discount: Discount | None = None) -> float:
    discount = discount or NoDiscount()  # Replace None with Null Object
    subtotal = sum(item.price * item.quantity for item in items)
    return discount.apply(subtotal)

# Both work without any null checks:
total_with_discount = calculate_total(items, PercentageDiscount(15))
total_without = calculate_total(items)  # Uses NoDiscount internally

Python’s __missing__ for Default Values

Python dicts have a built-in null object concept:

from collections import defaultdict

# Instead of:
counts = {}
for word in words:
    if word not in counts:  # Null check!
        counts[word] = 0
    counts[word] += 1

# Use defaultdict — the "null object" for missing keys:
counts = defaultdict(int)
for word in words:
    counts[word] += 1  # Missing key defaults to 0. No check needed.

Null Object vs Optional Chaining

Modern JavaScript/TypeScript has optional chaining (?.), which reduces null-check boilerplate:

// Optional chaining — concise but still branching
const theme = user?.preferences?.theme ?? "default";
user?.logger?.info("Profile loaded");

Optional chaining is great for reading values. But it doesn’t help when you need to call methods with side effects:

// Optional chaining can't do this cleanly:
user?.analytics?.track("page_view", { page: "/home" });
// If analytics is null, this silently does nothing — OK
// But if you need to log the failure, you're back to if-checks

// Null Object is better for dependencies with behavior:
class NullAnalytics implements Analytics {
  track(_event: string, _data: Record<string, unknown>): void {
    // Explicitly does nothing — this is intentional, not accidental
  }
}

Use optional chaining for property access. Use Null Objects for behavioral dependencies.

When to Use the Null Object Pattern

Use it when:

• An object has a meaningful “do nothing” default (loggers, caches, notifiers)
• You’re injecting optional dependencies into a class
• A function returns “no result” that callers iterate over (use empty collections)
• Null checks are cluttering your business logic

Don’t use it when:

• Null/absence has important semantic meaning (“this user has no address” vs “we haven’t loaded the address yet”)
• The null case requires special error handling (throw, don’t swallow)
• The interface is so large that a null implementation is burdensome to maintain
• You’d be hiding errors — sometimes null should crash loudly

The Danger: Hiding Bugs

The biggest risk with Null Objects is swallowing errors silently. If a payment processor is null and charges silently do nothing, you’ve got a serious problem:

// DANGEROUS: This should never be a null object
class NullPaymentProcessor implements PaymentProcessor {
  async charge(amount: number): Promise<PaymentResult> {
    return { success: true }; // Lies! No payment was actually made.
  }
}

The rule of thumb: use Null Objects for optional side effects (logging, caching, notifications), not for core business operations. If the operation failing should be an error, let it fail loudly.

Null checks aren’t inherently bad. But when they’re cluttering your code and obscuring the actual logic, the Null Object pattern gives you a clean alternative: an object that is nothing, but does it with grace.