Design pattern “to do nothing” a.k.a NullObjectPattern

Its been some time since i blogged, Thanks to my schedule , recently i was just going through some of the Design Patterns and this one stuck me hard. Yes, Design Pattern to do nothing! well how many times have we seen our code getting bombed due to the NPE a.k.a NullpointerException, or in other words how bad our code looks with “if conditions” to check if any of the objects are NULL. our code gets cluttered with these conditions to avoid NPE’s . NullObjectPattern is a pattern to avoid such a mishap in your code.

So what is this NullObjectPattern all about? Well, the author of this pattern Bobby Woolf feels that the solution lies in determining the earliest point which the reference could be NULL, and stifle it . so how to do all this?

Here is the example.

public List getList(String command){

if(command.equals(“A”)){return new ArrayList().add(“A”);}

if(command.equals(“B”)){return new ArrayList().add(“B”);}

if(command.equals(“C”)){return new ArrayList().add(“C”);}

else{ return null;}

//used as follows.
List listObj = getList();

//Do some thing after checking listObj for null.

Using NullObjectPattern

Everything remains same but only this “else{ return null;}” changes as follows

“else{ return null;}” gets changed to “else{ return new NullList();}”

public class NullList implements List(){

public void someMethod(){

logger.debug(“This Object is pointing to the null reference!”);




  1. I feel this takes care of NPE’s , more over we avoid those ” if ” conditions. yep if you mean some thing like we shouldnt be dealing with a code which returns “null” then it certainly make sense, i am with you on that, but when you come across such a situation i think this pattern is pretty good solution.. what say 🙂

  2. I think its more of a workaround – a coding tactic, rather than a Design pattern. The big problem here is every library will end up defining their own NullObjects, and you will have a bigger mess at your hands. null is java standard, easier to deal across various usages/libraries.

    Anyways it would be preferable to have a public static final reference – NullObjects.NullList, so as to avoid object proliferation.

  3. Yes,It is debatable whether this is a Design Pattern or just an coding tactic. The basic goal is to find a way to encapsulate the notion of how to “do nothing” in code. Yes to keep check on these NullObject proliferation in a library, framework, as you said, public static final signature is a good way to handle it.

  4. Why dont we just kill the null at the getList function itself..
    if(cmd==null) throw IAE(”command cannot be null”) ;
    >>Ok, fine. well if the parameter is say ‘z’ or any other input which isn’t A,B or C,Your method doesn’t return anything right? Just think about that.
    secondly, ” Why do we need a NullList class which does nothing ?”.
    The whole idea of this pattern is to avoid “Null Pointer Exceptions”, So when ever you come across the situation where in you gonna return Null use the dummy object which implements the return type(here in this case List). So you are avoiding the NULL and there is no need to check for null in the code which invoked your method. More over, you can use this dummy object to do some kinda things like logging, or anything which you may wish to do.

  5. hi ranganath,

    yes that seems to be fascinating. i think until and unless it has the interface implementation and polymorphic code in the way it is *actually* used in the code, we may have to have a check right? be it on the list’s size or if the list is of NullList?

    Does it make sense?

    Thanks for the post:)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s