The Null Pattern is a Good Thing

That’s all I’ve got to say this morning.  Check it our here:

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Scott

    Yes, it’s a great thing. I did a series of posts on it ( and as well.

    Nullability really should be a first class language citizen where the . operator is lifted so that calling a method or property on a null object simply returns null as well.

  • Kent Boogaart

    @Jeremy G: Conditionals are a code smell? Really? How long, then, until code is a code smell? 😉

    Like Joe, I am of the opinion that a nullo is good for an optional object. I just think of it as the nullo instance being the default state of the field rather than null being the default (almost like it’s a value type rather than a ref type). Providing a nullo for non-optional dependencies seems dangerous to me.

  • Jeremy Gray

    Conditionals are a code smell. Null/missing object pattern is a very nice way to eliminate a certain subset of said smell.

  • Dave Newman

    Having null be a first class object in the language would be even better!

    Ah ruby

  • Ben

    Here here

  • Joe

    Except for optional activities, I would agree with Bryan.

  • Jeremy D. Miller


    I guess that’s your point of view. For me it’s often a matter of using a nullo object that does nothing or putting in if/then logic. My vote is that the nullo object gives you cleaner code and fewer problems. The nullo is generally there for optional activities.

  • Bryan Watts

    Updated the article to remove the obvious bias.

  • Bryan Watts

    Let’s say I wanted to have a conversation with someone. I call them over to my desk, and start talking. If they show up, everything is fine. If I talk to thin air, my coworkers are going to question my sanity.

    The absence of an object when its presence is required is an exceptional situation. It means you can’t do the work you planned on because one of your prerequisites is not met.

    Martin Fowler suggests a “Special Case” object. That makes me laugh for 2 reasons:

    1. Instead of repetitive null-checking, you have repetitive derivations. The problem didn’t go away, it just takes more typing and artifacts to express it. This approach cascades all the way down every single inheritance hierarchy and could have just been solved with a simple null-check.

    2. What will NullCustomer.getPlan() do if not throw an exception? Will it return a NullPlan, which in turn returns other derivations?

    At some point, you have to address the absence of your target object. If that is not done on the *first* operation, in my opinion that violates the Principle of Least Surprise.

  • Kyle Szklenski

    Funny. For some reason, it always seemed like the *ultimate* in degenerative cases to have an object with no method bodies/default method bodies. Having said that, I’ve used it all over the place due to its usefulness!