The Null Object Pattern in PHP: Replacing Null Checks With a Neutral Object

1. What the Null Object Pattern Actually Solves

The Null Object pattern belongs to the behavioral patterns and solves a very everyday problem: instead of forcing an explicit null check at every call site for a possibly missing object, a concrete class is provided that implements the same interface but shows neutral, no-op behavior. A Null Object for a logger simply logs nothing, a Null Object for a discount calculator simply returns zero discount, without the calling code ever having to know whether a "real" or a neutral object is present.

The benefit of the Null Object pattern lies in radically simplifying the calling code. Instead of repeating if ($this->logger !== null) { $this->logger->info($message); } at twenty different places in the code, you simply call $this->logger->info($message), safe in the knowledge that $this->logger is never null, but at worst a Null Object that quietly ignores the call. This guarantee, never having to deal with actual null, is the core value the Null Object pattern provides.

In this article we show the Null Object pattern through several concrete examples, from a simple logger through repository patterns to combining it with the Strategy pattern, and clearly distinguish it from nullable types and the nullsafe operator, with which it is frequently confused even though both solve different problems.

2. Practical Example: a Neutral NullLogger

The classic entry point into the Null Object pattern is a logger that can optionally be passed into a class. Without the Null Object pattern, every method that potentially logs would first have to check whether a logger is present at all. With the Null Object pattern, a logger is always passed, typically a real one, and in the case of missing configuration a NullLogger that implements the LoggerInterface but gives every method an empty method body.

This technique is so widespread in the PHP community that the PSR-3 logging specification itself recommends equipping implementations with a NullLogger as a default value. Libraries that accept a logger as an optional dependency use this pattern consistently, so their own code never needs a null check for the logger parameter. The Null Object pattern shifts the responsibility for handling absence from the calling code into the class construction, where it only has to be decided once.

<?php

declare(strict_types=1);

interface LoggerInterface
{
    public function info(string $message, array $context = []): void;
    public function error(string $message, array $context = []): void;
}

// The Null Object — implements the interface, does effectively nothing
final class NullLogger implements LoggerInterface
{
    public function info(string $message, array $context = []): void
    {
        // Intentionally empty — this is the whole point of the pattern
    }

    public function error(string $message, array $context = []): void
    {
        // Intentionally empty
    }
}

final class OrderProcessor
{
    // Defaults to NullLogger instead of allowing null — no null checks needed anywhere
    public function __construct(
        private readonly LoggerInterface $logger = new NullLogger(),
    ) {
    }

    public function process(Order $order): void
    {
        $this->logger->info("Processing order {$order->id}");
        // ... business logic ...
        $this->logger->info("Order {$order->id} processed successfully");
    }
}

// Works identically whether a real logger or the default NullLogger is used
$processor = new OrderProcessor();          // silent
$processorWithLogging = new OrderProcessor(new FileLogger('/var/log/orders.log'));

3. Null Object in Repository and Finder Patterns

A second common application area for the Null Object pattern is repository and finder methods that might not return a result. Instead of declaring find() with ?Customer as the return type and forcing the caller to check for null every time, a method can return a NullCustomer object that implements the same Customer interface but delivers neutral values, for instance an empty name and an invalid but type-correct email address.

This application of the Null Object pattern is much more controversial than the logger case, because the absence of a customer is often a genuine, business-relevant piece of information that should not simply be papered over. A checkout process that accidentally continues working with a NullCustomer instead of treating the missing customer as an error can lead to inconsistent orders. The Null Object pattern here is best suited for read operations with low business consequence, for instance displaying a placeholder name in a log line, not for critical business decisions.

<?php

declare(strict_types=1);

interface CustomerInterface
{
    public function getDisplayName(): string;
    public function isRegistered(): bool;
}

final class RegisteredCustomer implements CustomerInterface
{
    public function __construct(
        private readonly string $firstName,
        private readonly string $lastName,
    ) {
    }

    public function getDisplayName(): string
    {
        return "{$this->firstName} {$this->lastName}";
    }

    public function isRegistered(): bool
    {
        return true;
    }
}

// Null Object for the "no customer found" case in low-stakes read paths
final class GuestCustomer implements CustomerInterface
{
    public function getDisplayName(): string
    {
        return 'Guest';
    }

    public function isRegistered(): bool
    {
        return false;
    }
}

final class CustomerRepository
{
    public function findByEmail(string $email): CustomerInterface
    {
        $row = $this->connection->fetchOne('SELECT * FROM customers WHERE email = :email', ['email' => $email]);

        // Returns a Null Object instead of null — no null-check burden on the caller
        return $row !== false
            ? new RegisteredCustomer($row['first_name'], $row['last_name'])
            : new GuestCustomer();
    }
}

4. Combining It With the Strategy Pattern

The Null Object pattern combines excellently with the Strategy pattern, especially where an optional behavior variant is modeled as a strategy. An example: a discount system defines a DiscountStrategyInterface with a method calculate(Order $order): Money. Instead of checking whether a discount strategy was assigned at all, a NoDiscountStrategy object is used when no discount applies, simply returning Money::zero().

This combination of Strategy and the Null Object pattern makes the calling code radically simpler: $order->applyDiscount($strategy->calculate($order)) works identically whether a real discount or no discount at all is in play. The conditional branch that would otherwise have to check whether a discount even exists disappears completely from the business logic and instead moves into the decision of which strategy instance is selected when the object is created.

<?php

declare(strict_types=1);

interface DiscountStrategyInterface
{
    public function calculate(Order $order): Money;
}

final class PercentageDiscountStrategy implements DiscountStrategyInterface
{
    public function __construct(private readonly float $percentage)
    {
    }

    public function calculate(Order $order): Money
    {
        return $order->getSubtotal()->multiply($this->percentage / 100);
    }
}

// Null Object: same interface, zero effect — no conditional branching needed
final class NoDiscountStrategy implements DiscountStrategyInterface
{
    public function calculate(Order $order): Money
    {
        return Money::zero($order->getSubtotal()->getCurrency());
    }
}

final class Order
{
    private DiscountStrategyInterface $discountStrategy;

    public function __construct()
    {
        $this->discountStrategy = new NoDiscountStrategy();
    }

    public function applyDiscountStrategy(DiscountStrategyInterface $strategy): void
    {
        $this->discountStrategy = $strategy;
    }

    public function getTotal(): Money
    {
        // Works identically for real discounts and the "no discount" Null Object
        return $this->getSubtotal()->subtract($this->discountStrategy->calculate($this));
    }
}

5. A Null Object as a Shared Singleton Instance

Since a Null Object is by definition stateless and holds no internal data that would need to vary between different uses, it often makes sense to use a single shared instance instead of creating many new objects. A static factory method call like NullLogger::instance() with internal singleton management saves unnecessary object creation without changing the semantics of the Null Object pattern.

This optimization is especially relevant in code paths that run frequently, for instance on every HTTP request. Important here: the shared instance really must not hold any mutable state, otherwise unexpected side effects could occur between different users of the same object. For a genuine Null Object, which by definition does nothing, this condition is practically always met, which makes the singleton optimization risk-free.

6. Limits: When a Null Object Does Not Fit

The Null Object pattern is not a universal tool against every form of null. Where the absence of a value carries business-relevant information that requires a deliberate decision by the calling code, a Null Object masks exactly that necessary decision. A payment service that returns a NullPaymentMethod when no payment method is present, silently processing no payment, hides a critical error state that would actually have deserved an exception or at least explicit error handling.

A second problem arises when too many different Null Object variants exist for the same interface, each with slightly different neutral behavior. That leads to confusion about which "nothing" is meant in which context. The rule of thumb: the Null Object pattern is suited for cases where "do nothing" or "neutral value" has a sensible, unambiguous semantics, not for cases where absence is actually an error state that needs visibility rather than concealment.

7. Distinguishing From Nullable Types and the Nullsafe Operator

The Null Object pattern is frequently confused with nullable types (?Type) and the nullsafe operator (?->), even though both solve different problems. Nullable types and the nullsafe operator make dealing with actual null more convenient by allowing chains like $user?->getAddress()?->getCity() without nested if checks. The Null Object pattern, on the other hand, avoids null completely by replacing it with a real object of neutral behavior.

The decisive difference shows up at the method call: with the nullsafe operator, a chain like $user?->getLogger()?->info($message) simply returns null and does nothing if the logger is missing, which at first glance looks similar to the Null Object pattern. The difference lies in consistency: the nullsafe operator has to be repeated at every single call site, while the Null Object pattern makes the decision exactly once at object creation time and afterwards allows normal method calls everywhere in the code, without having to repeat ?-> at every spot.

8. Null Object in Tests: Simpler Than Mocking for Edge Cases

An often overlooked advantage of the Null Object pattern shows up when testing edge cases. Instead of configuring a mock object with a null return for every test that is meant to simulate the absence of an optional object, you can simply inject the regular Null Object implementation. That reduces test code boilerplate and makes tests more robust against refactoring, because the Null Object is part of the production codebase and evolves with it, instead of being isolated and reconfigured in every test.

This property makes the Null Object pattern especially attractive in test suites that need to cover many variants "with and without an optional dependency". A test for OrderProcessor without a logger does not need to set up a mock, it simply uses the default value new NullLogger(), which is already part of the class definition anyway. That not only saves lines but also reduces the likelihood that a mock accidentally shows different behavior than the actual production implementation of the Null Object.

9. Null Object Compared to Alternatives

The following table compares the Null Object pattern to the most common alternatives for dealing with missing values and objects in PHP.

The table makes clear: the Null Object pattern minimizes effort for the calling code the most, but deliberately conceals the absence in exchange. That is exactly why the choice between the four approaches is not a mere matter of style, it depends on whether the absence of an object is business-relevant or can genuinely be treated as neutral.

10. Summary

The Null Object pattern replaces missing objects with a concrete implementation of the same interface that behaves neutrally, instead of forcing an explicit null check at every call site. For optional, uncritical dependencies like loggers or discount strategies, the Null Object pattern reduces the calling code to normal method calls, without ever having to deal with real null.

The limit of the pattern lies where the absence of an object carries business-relevant information that requires a deliberate decision. Here the Null Object pattern conceals exactly the information that should be made visible, and an exception or explicit error handling is the better choice. Anyone who draws this line clearly uses the Null Object pattern exactly where it genuinely simplifies code, without hiding important error states.

11. FAQ: Null Object Pattern in PHP