Archived

This topic is now archived and is closed to further replies.

Clash

Thoughts on Null Objects

Recommended Posts

Clash    342
I''ve been writing a GUI Framework using a Test Driven Approach, and I''m finding lots of situations in which introducing a Null Object would simplify my code quite a bit. I was just wondering what everyone''s thoughts and opinions are about their use. - Jason Citron - www.jasoncitron.net

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
There have been several instances where implementing a null object concept would have reduced the size of a function. However there is a reasonable arugement against the null object concept. When u encounter a null ptr or an invalid ptr you can handle the error at that spot, which usually is closer to the source of the error. With the null object, it''s possible for it to slip through the cracks, and eventually reach verification code which could be far from the source of the error.

Correct me if im not mistaken, the null object is a opertable object which is used to indicate an invalid object. So code doesnt need to check if the target of the operation is invalid, rather the obejct itself checks for this. There are other issues such as multiple null objects is a possiblity.

Seems like the null object could work, but it wouldn''t reside at the level of the user program, rather it has to be much lower, univerisal to the language itself. Maybe C# has such a concept.

-ddn

Share this post


Link to post
Share on other sites
Zahlman    1682
The null object doesn't have to be used to represent an "invalid" object, it can represent the "lack of any real" object in a place where it's reasonable for that situation to exist. I'm a huge fan of it for this use, largely because I'm a Java programmer and I don't particularly like dealing with exceptions, especially runtime ones (except as a debugging tool).

One pattern I have is, when a base class would normally be abstract, to instead use instances of an unspecified base class as null objects. Then subclasses override mostly blank methods rather than implementing over a "virtual" layer.

E.g.

class Bar {
protected static int[] NO_DATA = new int[0];

protected int[] mydata;
public void wibble() {}
public boolean isTangible() {return false;}
public final int getData() {return mydata;}
// I know that last one isn't a terribly good thing to have in OO code, but it's useful for the example

public final String toString() { return super.toString() + " (" + (isTangible ? "" : "in") + "tangible)"; } // will use the subclass' isTangible() - template/hook methods, whee

}

class FooBar extends Bar {
public void wibble() { // do something!

}
public boolean isTangible() { return true; } // probably true in most subclasses... ?

}

class BarUser {
private Bar mybar;
public BarUser(Bar mybar) { this.mybar = mybar; }
public void wibble() {
mybar.wibble(); // can't throw NullPointerException if we're diligent about using the NullObject pattern.

// If there's no real Bar in place, just returns silently, and probably with less overhead than a try-catch for NPE

doSomeBarUserLevelWibbling();
}
public String toString() { return super.toString + "
which uses " + mybar; }
}


[edit: For large blocks of code, use source instead of code tags]

[edited by - Magmai Kai Holmlor on January 12, 2004 11:02:27 AM]

Share this post


Link to post
Share on other sites