The Null Object says, "Just because I don't have anything and don't do anything, it does not mean that I am not smart. By not having anything, I don't take up much resource and can be shared among many. By not doing anything, I am doing the right thing."
In much of the current programming practice, the special value null is often used as a flag to represent a gamut of different and often disconnected concepts such as emptiness and falseness. This can result in a lot of confusion and complex control structures in the code. In our view, null should only be used to denote the non-existence of an object. null is not an object and has no "intelligence" (i.e. behavior) for other objects to interact with. Therefore, whenever we work with a union of objects and discover that one or more of these objects may be referencing a null value, we almost always have to write code to distinguish null as a special case. To avoid this problem, we should think of adding a special object, called the null object, to the union with appropriate behavior that will allow us to treat all object references in a consistent and uniform way, devoid of special case consideration. This design pattern is called the null object pattern. We have used the null object pattern in several occasions, the most notable one being the NullNode to represent the empty state of a (mutable) list. We also used a null object called NullDrawable in the hangman program. NullDrawable is a singleton and appears in the code for BodyPartsCanvas as the initial value for the private field _drawing. It is there to guarantee that _drawing is always referencing an IDrawable object, and , since setDrawable only allows a non-null assignment, the code for paintComponent is always executed without checking _drawing for null.
public class BodyPartsCanvas extends JPanel
{
private IDrawable _scaffold = new Scaffold ();
private IDrawable _drawing = NullDrawable.Singleton;
public void setDrawable(IDrawable doodle)
{
if (null != doodle) // check
against the input parameter, and not against _drawing.
{
_drawing = doodle;
}
}
public void paintComponent (Graphics g)
{
super.paintComponent (g);
_scaffold.draw (g);
_drawing.draw (g); // something
is always drawn here.
}
}
The problem of null reference comes up again when we try to move a body part from one list to another. Here is the code of the left button's action listener.
_rightBPList.insertEnd (_leftBPList.removeFront ());
Here we remove a body part from the front of the left list and insert it into the end of the right list. When the left list becomes empty, what should we do? In the implementation given in the lab, the empty list throws an exception on the removal operations (removeFront, removeEnd) . We can try to handle the empty list nasty behavior by the following elementary solutions.
The null object pattern suggests that instead of returning null, we should program the empty list to return the NullDrawable singleton. If we do so, at some point in the program's run time, we might be executing something like this:
_rightBPList.insertEnd (NullDrawable.Singleton);
As it currently stands, the NullDrawable object will be inserted into the right list. And if we keep clicking the left button, the right list will keep inserting more NullDrawable objects, one for each click. This will appear OK on the canvas since the NullDrawable object does not draw anything. However, a problem will surface when we start moving body parts from the end of the right list to the front of the left list by clicking on the right button. For a while nothing seems to happen because we are just moving the NullDrawable object and nothing is drawn. This is not OK because we only sees regular body parts and we expect to see them move one at a time on each click of a button.
What we want is for the BPList not to insert the NullDrawable object at all. But what we don't want is to have to write code to check for the type of body parts before or inside of the insertion operations (insertFront, insertEnd). The problem here stems from the fact that the insertion operations depend not only on the receiver (BPList) but also on the input parameter, which, in this case, is the body part object. So the insertion operations depends on two types: the type of its receiver, and the type of its parameter. In the language of pattern, this is called double-dispatch.
The double-dispatch pattern is a design solution to the problem of double-dispatching for languages that do not support this concept directly. When applied to the BPList insertFront method for example, it works as follows.
The code to remove a body part from the front of the left list and insert it into the end of the right list will now look like:
_leftBPList.removeFront ().enterEnd (_rightBPList);
There is no ifs, no buts, no conds, no switched, no nothing! Only objects requesting other objects to do their jobs. The program's control flow is directed by the underlining polymorphism machinery. The programmer is freed from writing control statements. The program as a whole is glued together by the architecture of the object model and not by contorted control code, and thus is more robust and easily maintained.
Below is the UML diagram describing the null object pattern and the double-dispatch pattern applied to the hangman body parts and body parts list.