1.6 Null design pattern

The Null Pattern is perhaps the most "intelligent" pattern of them all. It knows exactly what to do all the time, every time: nothing. Its usefulness is a little more subtle than that of other Design Patterns, but it can be used in many different situations.

The Null Pattern is somewhat difficult to describe, since it resides in an abstract hierarchy tree, having no particular place at all, but occupying many roles. It is somewhat like the mathematical concept of zero: it is a placeholder, but is in itself nothing, and has no value. However, this means that Null is abstractly equivalent to any of the other concrete classes in the abstract hierarchy. Thus, it can be treated identically to any other class by the system. This gives consistent and predictable behavior for the null situation. Some objects' behavior will depend upon its values, and since the Null Pattern has no values, it knows exactly what to do every time. It really does do nothing . And that's the most reliable code you'll ever see.

One of the uses of the Null pattern is in the context of a Strategy Pattern . You have several behaviors that you want your host object to perform, but what if you want it to just do nothing? That's where you use a Null Pattern. The Null Pattern complies with the interface for a Strategy, but the bodies of its methods are blank, so it does nothing.

Another popular use of the Null Pattern is in the context of a State Pattern . The easiest way to separate objects into two categories is along the difference between Null and Non-Null. Non-Null objects have values and do things, whereas Null ones do not. When working with a singly linked list, the Null node of the list is arguably the most important node in the list. It is the only node in the entire list that "knows what to do." When you perform a tail recursive operation on a singly linked list, each node asks the remaining portion of the list for more information in order to complete the assigned task. (remember: a singly linked list is defined in terms of nodes. Each node has a value ( car ) and a reference to the rest of the list. ( cdr ) The end of the list is reached when a node has no cdr.) It is only upon reaching the last node, the Null node, that any actual operations can be completed. The Null node will know exactly what to do: Nothing. Based upon this, the recursive calls made upon the elements of the list can be resolved, since there is a definite value to work with.

Let's say that you have a list of objects that need to be drawn in a certain Container object (context). These objects are extensions of list nodes, and have only one extra method in them, which is the paint method. Each node's paint method consists of it asking its cdr to draw, and then actually drawing whatever it is that they draw onto the context. When you ask the first node to paint, it will ask the next node to paint, which will ask the next node to paint, and so on. How can we make this useful and not just a silly infinite delegation? The paint method of the last (and, supposedly, Null) node is empty. This means that it will do nothing, ant then return to the previous method that called it, so that all of the recursive calls down the list can resolve. This allows us to have an indefinite number of things to be painted in the list that can appear in any order. The only node in the list that matters is the last, Null node, which is the only one that actually knows what to do.