The Null Pattern is a Good Thing

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 http://codebetter.com/jeremymiller.

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.

http://kentb.blogspot.com/ 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.

http://sentia.com.au/blog 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.

http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

@Bryan,

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.

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!