[drfrank]

As I understand it, this article misrepresents the purpose and nature of the Null Object Pattern ("NOP").

The author cites a comment that describes (very) vaguely a "hotel booking" example, expressing the idea that "None" is the null object. But "None" is not an instance of the NOP. None has no interface. You can't tell None to do something.

In contrast, an acutal implementation of the NOP might be in a travel reservation service which allows you to reserve both a hotel and a rental car at the same time. Somewhere in the guts of that service there might be a Trip object.

  class Trip
  {
    Car car;
    Hotel hotel;
  
    public void Reserve()
    {
      this.car.Reserve();
      this.hotel.Reserve();
    }
  . . .
  }

A Trip can be constructed with a NullCar when the user doesn't want to reserve a car on this trip. When NullCar::Reserve is invoked, it doesn't do anything, but Trip doesn't care, and the implementor of Trip doesn't need to remember to check its car to see if it's null before invoking it.

I've encountered this misconception frequently, and it typically stems from the common understanding of object oriented programming as programming in terms of entities which represent physical objects in the real world. I deduce that the author uses this definition from the sentence "It is also interesting to note that appearances of null objects are virtually non-existent in real life."

Objects aren't necessarily representations of physical entities. Objects are simply things other objects (or procedural code) can use to accomplish something without having to know how to accomplish that thing.

I've found the distinction that Alan Kay has (repeatedly) made useful in helping people understand this idea: Property accessors aren't for objects, they're for Data Structures.

So, when the author says that, "the basic idea of the null object pattern is exactly the same as for practices like 'use zero instead of null'", my reply is, "No, it's not called the 'Null Data Structure Pattern'." Use zero instead of null is (flawed) advice about how to write data structures, not how objects should be constructed. The NOP is not used to build objects that represent data, it is used to build objects that represent action. The author's repeated use of the GetCustomer example is inappropriate for the NOP. It's much more likely that a database record is represented using a data structure than an object.

Pragmatically, if you feel the desire to ask an object if it is the NullObject, you are not writing object-oriented code, you are writing procedural code. Instead of asking if the object is the NullObject, move the branch that would be invoked if the object were the null object into a method present in the interface that the NullObject implements. Perhaps you find that you don't actually have a NullObject, after all.