Skip to main content


14 replies [Last post]
Joined: 2003-06-06

Welcome to our bookclub discussion of Joshua Kerievsky's book "Refactoring to Patterns". You can read an excerpt from the book on Introducing Null Object. Pick up a copy of the book and join Joshua, who has kindly agreed to host this discussion.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-19

IMO, that is included in a more general refactoring 'Replace null reference with an object', but is not the Null Object pattern. Not all refactorings directly relate to patterns.

The use of null instead of an empty object is an anti-pattern. It can make life a little more convenient for client code, as used randomly in the Java libraries, but generally is not nice. An empty object is not a Null Object.

It's worth noting that Object[0], "", Collections.emptySet, etc., are immutable. A single instance can therefore be used where a new object would usually be required. A reference to a shared immutable does not consume any more memory than a null reference.

Joined: 2003-06-19

I think there is a line between responsible defencive programming and covering up bugs. If you check your arguments, assert internal products and generally throw at the first sign of trouble, then everything should be fine. Trying to carry on with corrupt data is disastrous (different rules apply for nuclear power stations).

In my opinion it is unfortunate that Java doesn't allow nullness or not to be part of the static type checking. NPE could have been made a checked exception. In some circumstances it worries me using the Null Object pattern that I may have missed a check somewhere.

I am not convinced by your example. A better solution is to break the cyclic dependency between the two controls.

Joined: 2003-06-18

The Null object pattern and a null pointer are far from equal. It is unfair to equate using Null Object with lack of design or attention to detail. If Null Object is used I would say the chances are good that some design and thought have gone into the code. I don't think your average inexperienced programmer is going to be using Null Object much. They probably haven't heard of it or understand it.

I also think Null Object is defensive programming. It protects the code from self destructing. Lot's of null pointer checks isn't the only way to make sure your code is robust.

Joined: 2003-12-02

NullObject pattern is often advocated as a cheap way to prevent NullPointerExceptions.
In that context it is lack of design, certainly if the NullPointerException could otherwise have been avoided.

The only thing a Null object (and you'd need to define them for every single class you use, leading to massive code bloat) does is move those checks up a level.
In addition you're going to complicate your object assigments and/or have to do a lot of checking for null anyway and follow up every null with an assignment to the null object.
Doesn't make the code any easier to follow.

Joined: 2003-06-19

I thought it was a curious example in the excerpt. The problem disappears with the "new" 1.1 event model. Are there many people still programming for 1.0? And back then, with 14.4k modems, ropey HTTP software and before jars, there was more concern to keep the class count down.

I have used the Null Object pattern to simplifier zero or one observer/listener codessh -l tackline . However, a possibly better and more general solution is to replace unicasting with a multicast. javax.swing.event.EventListenerList is your friend, even if it should be in java.beans.

I see the Null Object pattern primarily to substitute for missing lower level types. NullOutputStream, placeholder in Queues, etc. Not so much for callbacks, nor for peers.

Joined: 2004-10-04

Under my understanding of the null object pattern, my two favorite examples of null objects are 'new Object[0]' and '""'. These values are underused, and provide the same nice behaviour as null objects. (are they considered null objects?)

Joined: 2004-03-04

A relative of mine programs with SAS, and he scoffs at my puny SQL nulls. I was like 'so whats the problem?' and he then rattled off a dozen or so different kinds of 'null'.

I don't remember them all, but here's a short list:

(1) Empty
(2) Never been instantiated
(3) Used to be something, but has been erased
(4) Unknown
(5) Error
(6) Used to be a valid value, but isn't anymore

Dates are another area where this gets tricky, eg in SQL dates are often stored as date/time, but what if you want a date without a time, or a time without a date. What if you know a date only partially (eg sometime in October).

In OO a null often serves as a 'third return' from a method. A method might return a value, it might throw an exception, or it might return a null, they can all be used to indicate different things. Eg returning a null might mean something like "you gave me bad parameters".

This might be better than throwing an exception, depending on how you want to handle it.


try {
} catch {

If 'a' throws an exception, 'b' and 'c' never get called, whereas if 'a' returns a null (or empty: eg your empty object array or empty String) then you can still proceed through to 'b' and 'c' if you want or need to. Its not necessarily better, its just another option.

Joined: 2003-12-04

I can remember… way back in the day…. when Joshua was first starting Refactoring to Patterns and I used to argue with Joshua “Don’t teach the patterns, just teach the principles that lead to the patterns” it didn’t take me long to change my tune. Then I was hounding him “When are you gonna get that book out? We need that book out.” Now I suspect that this will be one of the three most important books an Object Oriented developer can read. Thank you Joshua.

Joined: 2003-12-02

You were right though, dumping a load of patterns on someone's desk (in the form of a thick book most likely) isn't going to help anyone.
Unless you know how to recognise where a pattern would be appropriately used (distill the pattern from the problem) a pattern is no use.

That's where most pattern books go wrong, they're indeed just a long list of patterns with nothing to bind them to usage scenarios.
They're like a shopping list for a 10 course christmas dinner without the recipes and menu card. All nice things to have but what to do with them?

Joined: 2004-01-30

I recently finished reading [i]Refactoring to Patterns[/i], excellent book.

Null Object is one of the most useful patterns; I use all the time. It is especially useful for observers and those types of objects. With a Null Object I don't have to continually check to see if the observer has been specified. If one has not been specified, the notification just goes to a Null Object which does nothing.

Joined: 2004-03-04

I don't like the NullObject pattern.*

I can see why people like it (makes code shorter, less thinking, etc).

I program very very defensively. I *like* to have lots of checks for nulls all over the place. Typically they will spit out some form of abuse to the command line, and we will catch it and fix it in development.

A NullPointerException isn't something you should fix with a null pointer object, it is something you should fix with your design. If your design is wrong you will save 10x the grief and agony by fixing the design than you ever would with this kind of coat of paint pattern.

Just tell the designer 'fix the design you lazy bum'.

Programmers that don't program defensively as a natural reflex should be moved into management ASAP. If there aren't any management positions, make them do testing, helpdesk or user support instead. They will soon come to appreciate the value of a robust application!!!

* There is ONE place where this 'pattern' is useful, but a Pattern should be useful in MANY places to qualify as a Pattern. That is where you have two controls (typically in an UI) which need to listen to each others events, but when you assign them as a listener they will fire an event, so you can get events being sent to things which haven't finished constructing themselves etc. It can be a pain to sort out. NullObject helps because you can use it to 'put the events on hold' until you are ready to turn them on. But even that you can code around without the pattern if you are good (defensive) enough.

Joined: 2003-07-13

"null" usually signifies an error of cause "something was not initialized". When a reference is a Null object, then it has been explicitely initialized as such. It purpose is not to hide npe's. A Null object should be used to express that "I want to prevent method calls to the object from throwing exceptions - I don't need the object, I just need to keep the rest of the code working". This is different from a null reference.

Joined: 2004-03-04

The fundamental problem with objects being used when uninstantiated is one of laziness or lack of understanding on the designers or developers part.

It indicates that they haven't spent enough time thinking about how the parts of the program will fit together and the order in which things get invoked.

One of the contractors at work recently put something into Production which is regularly getting Null Pointer errors, and when I found out I just about did my nut at them. The irony of yelling at someone about how clueless and unprofessional they were did not escape me, so I restrained myself. :D

A good coder will have the pride in their work to eliminate those kinds of bugs.

Brushing them under the carpet, or covering them with a coat of paint is irresponsible. Null pointer exceptions are like major structural errors in a house. You don't just paint over the huge crack running from floor to ceiling and hope noone notices it, you fix the fundamental problem.

Joined: 2003-06-19

In the book's example the event handler could not have been constructed in time. At least not without hanging.

A good coder will try to eliminate the UI hanging on I/O operations. Brushing the problem under the carpet is irresponsible.