In object-oriented computer programming, a Null Object is an object with defined neutral ("null") behavior. The Null Object design pattern describes the uses of such objects and their behavior (or lack thereof). It was first published in the Pattern Languages of Program Design book series.^[1]

Motivation

In most object-oriented languages, such as Java or C#, references may be null. These references need to be checked to ensure they are not null before invoking any methods, because methods typically cannot be invoked on null references.

Description

Instead of using a null reference to convey absence of an object (for instance, a non-existent customer), one uses an object which implements the expected interface, but whose method body is empty. The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.

For example, a function may retrieve a list of files in a directory and perform some action on each. In the case of an empty directory, one response may be to throw an exception or return a null reference rather than a list. Thus, the code which expects a list must verify that it in fact has one before continuing, which can complicate the design.

By returning a null object (i.e. an empty list) instead, there is no need to verify that the return value is in fact a list. The calling function may simply iterate the list as normal, effectively doing nothing. It is, however, still possible to check whether the return value is a null object (e.g. an empty list) and react differently if desired.

The null object pattern can also be used to act as a stub for testing if a certain feature, such as a database, is not available for testing.

Relation to other patterns

It can be regarded as a special case of the State pattern and the Strategy pattern.

It is not a pattern from Design Patterns, but is mentioned in Martin Fowler's Refactoring^[2] and Joshua Kerievsky's^[3] book on refactoring in the Insert Null Object refactoring.

Chapter 17 is dedicated to the pattern in Robert Cecil Martin's Agile Software Development: Principles, Patterns and Practices^[4]

In various languages

C

In C, functions can be written such that they accept a null pointer without failing. For instance the standard function free may be called with a null argument. This allows code like

free(p);
p = NULL;

to be safely executed two or more times.

C++

A language with statically typed references to objects illustrates how the null object becomes a more complicated pattern:

class animal {
public:
  virtual void make_sound() = 0;
};
 
class dog : public animal {
  void make_sound() { cout << "woof!" << endl; }
};
 
class null_animal : public animal {
  void make_sound() { }
};

Here, the idea is that there are situations where a pointer or reference to an animal object is required, but there is no appropriate object available. A null reference is impossible in standard-conforming C++. A null animal * pointer is possible, and could be useful as a place-holder, but may not be used for direct dispatch: a->make_sound() is undefined behavior if a is a null pointer.

The null object pattern solves this problem by providing a code special null_animal class which can be instantiated bound to an animal pointer or reference.

The special null class must be created for each class hierarchy that is to have a null object, since a null_animal is of no use when what is needed is a null object with regard to some widget base class that is not related to the animal hierarchy.

C#

C# is a language in which the Null Object pattern can be properly implemented. This example shows animal objects that display sounds and a NullAnimal instance used in place of the C# null keyword. The Null Object provides consistent behaviour and prevents a runtime Null Reference Exception that would occur if the C# null keyword were used instead.

/* Null Object Pattern implementation:
 */
using System;
 
// Animal interface is the key to compatibility for Animal implementations below.
interface IAnimal
{
    void MakeSound();
}
 
// Dog is a real animal.
class Dog : IAnimal
{
    public void MakeSound()
    {
        Console.WriteLine("Woof!");
    }
}
 
// The Null Case: this NullAnimal class should be instantiated and used in place of C# null keyword.
class NullAnimal : IAnimal
{
    public void MakeSound()
    {
        // Purposefully provides no behaviour.
    }
}
 
/* =========================
 * Simplistic usage example in a Main entry point.
 */
static class Program
{
    static void Main()
    {
        IAnimal dog = new Dog();
        dog.MakeSound(); // outputs "Woof!"
 
        /* Instead of using C# null, use a NullAnimal instance.
         * This example is simplistic but conveys the idea that if a NullAnimal instance is used then the program
         * will never experience a .NET System.NullReferenceException at runtime, unlike if C# null was used.
         */
        IAnimal unknown = new NullAnimal();  //<< replaces: IAnimal unknown = null;
        unknown.MakeSound(); // outputs nothing, but does not throw a runtime exception        
    }
}

Smalltalk

Following the Smalltalk principle, everything is an object, the absence of an object is itself modeled by an object, called nil. In the GNU Smalltalk for example, the class of nil is UndefinedObject, a direct descendant of Object.

Any operation that fails to return a sensible object for its purpose may return nil instead, thus avoiding the special case of returning "no object". This method has the advantage of simplicity (no need for a special case) over the classical "null" or "no object" or "null reference" approach. Especially useful messages to be used with nil are isNil or ifNil:, which make it practical and safe to deal with possible references to nil in Smalltalk programs.

Common Lisp

In Lisp, functions can gracefully accept the special object nil, which reduces the amount of special case testing in application code. For instance although nil is an atom and does not have any fields, the functions car and cdr accept nil and just return it, which is very useful and results in shorter code.

Since nil is the empty list in Lisp, the situation described in the introduction above doesn't exist. Code which returns nil is returning what is in fact the empty list (and not anything resembling a null reference to a list type), so the caller does not need to test the value to see whether or not it has a list.

The null object pattern is also supported in multiple value processing. If the program attempts to extract a value from an expression which returns no values, the behavior is that the null object nil is substituted. Thus (list (values)) returns (nil) (a one-element list containing nil). The (values) expression returns no values at all, but since the function call to list needs to reduce its argument expression to a value, the null object is automatically substituted.

CLOS

In Common Lisp, the object nil is the one and only instance of the special class null. What this means is that a method can be specialized to the null class, thereby implementing the null design pattern. Which is to say, it is essentially built into the object system:

;; empty dog class
 
(defclass dog () ())
 
;; a dog object makes a sound by barking: woof! is printed on standard output
;; when (make-sound x) is called, if x is an instance of the dog class.
 
(defmethod make-sound ((obj dog))
  (format t "woof!~%"))
 
;; allow (make-sound nil) to work via specialization to null class.
;; innocuous empty body: nil makes no sound.
(defmethod make-sound ((obj null)))

The class null is a subclass of the symbol class, because nil is a symbol. Since nil also represents the empty list, null is a subclass of the list class, too. Methods parameters specialized to symbol or list will thus take a nil argument. Of course, a null specialization can still be defined which is a more specific match for nil.

Scheme

Unlike Common Lisp, and many dialects of Lisp, the Scheme dialect does not have a nil value which works this way; the functions car and cdr may not be applied to an empty list; Scheme application code therefore has to use the empty? or pair? predicate functions to sidestep this situation, even in situations where very similar Lisp would not need to distinguish the empty and non-empty cases thanks to the behavior of nil.

Criticism

This pattern should be used carefully as it can make errors/bugs appear as normal program execution.^[5]

See also

• Nullable type
• Option type

External links

• Jeffrey Walkers' account of the Null Object Pattern
• Martin Fowlers' description of Special Case, a slightly more general pattern
• Null Object Pattern Revisited
• Introduce Null Object refactoring
• SourceMaking Tutorial

References

1. ^ Woolf, Bobby (1998). "Null Object". In Martin, Robert; Riehle, Dirk; Buschmann, Frank. Pattern Languages of Program Design 3. Addison-Wesley 
2. ^ Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN 0-201-48567-2. 
3. ^ Kerievsky, Joshua (2004). Refactoring To Patterns. Addison-Wesley. ISBN 0-321-21335-1. 
4. ^ Martin, Robert (2002). Agile Software Development: Principles, Patterns and Practices. Pearson Education. ISBN 0-13-597444-5. 
5. ^ Fowler, Martin (1999). Refactoring pp. 261