Null object pattern: Difference between revisions

Revision as of 02:45, 29 February 2024

Latest revision as of 09:55, 29 July 2025

(6 intermediate revisions by 6 users not shown)

Line 1:

{{Short description|Object with no referenced value or with defined neutral ("null") behavior}}

{{Redirect|Null object|the concept in category theory|Initial object}}

In [[Object-oriented programming|object-oriented]] [[computer programming]], a '''null object''' is an [[Object (computer science)|object]] with no referenced value or with defined neutral (''null'') behavior. The null object [[design pattern]], which describes the uses of such objects and their behavior (or lack thereof), was first published as "Void Value"<ref>{{Cite conference

| first = Thomas

| last = Kühne

Line 31:

{{Unreferenced section|date=June 2023}}

Instead of using a [[null reference]] to convey the absence of an object (for instance, a non-existent customer), one uses an object which implements the expected [[Interface_(computing)#In_object-oriented_languages | interface]], but whose method body is empty. A key purpose of using a null object is to avoid conditionals of different kinds, resulting in code that is more focused, and quicker to read and follow{{snd}} i.e. improved readability.

One 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''.

Line 82:

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

It is not a pattern from ''[[Design Patterns (book)|Design Patterns]]'', but is mentioned in [[Martin Fowler (software engineer)|Martin Fowler's]] ''Refactoring''<ref>{{cite book

| first = Martin

| last = Fowler

Line 173:

<syntaxhighlight lang="cpp">

import std;

#include <iostream>

class Animal {

Line 182:

};

class Dog : public Animal {

public:

virtual void MakeSound() const override { std::cout << println("woof!" << std::endl); }

};

class NullAnimal : public Animal {

public:

virtual void MakeSound() const override {}

Line 277:

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

Any operation that fails to return a sensible object for its purpose may return <code>nil</code> instead, thus avoiding the special case of returning "no object" unsupported by Smalltalk designers. 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 <code>nil</code> are <code>isNil</code>, <code>ifNil:</code> or <code>ifNotNil:</code>,, which make it practical and safe to deal with possible references to <code>nil</code> in Smalltalk programs.

===Common Lisp===

Line 336:

=> nil

</syntaxhighlight>

Attempts to directly [[Monkey patch|monkey-patch]] NilClass instead of providing explicit implementations give more unexpected side effects than benefits.

===JavaScript===

Line 469:

==Criticism==

This pattern should be used carefully, as it can make errors/bugs appear as normal program execution.<ref>Fowler, Martin (1999). Refactoring, ppp. &nbsp;216.</ref>

Care should be taken not to implement this pattern just to avoid null checks and make code more readable, since the harder-to-read code may just move to another place and be less standard—such as when different logic must execute in case the object provided is indeed the null object. The common pattern in most languages with [[reference type]]s is to compare a reference to a single value referred to as null or nil. Also, there is an additional need for testing that no code anywhere ever assigns null instead of the null object, because in most cases and languages with static typing, this is not a compiler error if the null object is of a reference type, although it would certainly lead to errors at run time in parts of the code where the pattern was used to avoid null checks. On top of that, in most languages and assuming there can be many null objects (i.e., the null object is a reference type but doesn't implement the [[singleton pattern]] in one or another way), checking for the null object instead of for the null or nil value introduces overhead, as does the singleton pattern likely itself upon obtaining the singleton reference.

==See also==