

Null Object: Something for Nothing (2003) - furikuri
http://www.researchgate.net/publication/242408118_Null_Object_Something_for_Nothing

======
niccaluim
I'm surprised* there's no mention of Objective-C's behavior when passing
messages to nil. Nothing blows up; the message either returns 0 or an empty
struct, depending on its return type. In actual practice this can sometimes
result in weird behavior, but overall I always thought it was a very humane
feature of the language.

*Well, ok, not /that/ surprised, given the year of publication, but Objective-C did at least exist at the time.

~~~
louthy
That seems like a bad idea. It potentially moves the failure further away from
the cause. It's nearly always better to fail fast and deal with the problem,
than propagate. Obviously it'd be even better to not have null at all, or have
a null that doesn't claim to honour a contract that it can't fulfil
(Option/Maybe type basically).

For C# programmers I attempted to help fix the problem[1] (it papers over the
cracks):

[1] [https://github.com/louthy/language-
ext](https://github.com/louthy/language-ext)

~~~
pavlov
In Objective-C, you generally don't treat messaging-to-nil as a failure but a
common occurrence. It's a different approach to API design, really.

I write much more Obj-C than Java, and I'm always kind of surprised going back
to Java that null is such a big boogaboo all over the place. Considering how
much influence Obj-C had on Java, it's a shame Sun didn't adopt "benevolent
nil".

~~~
Retra
It seems a little odd to write code intending for it to do nothing. If that
isn't a recipe for obfuscation...

~~~
masklinn
It fits the tenets of OOP though, you ask an object to perform an operation,
the "null" object just ignores the request.

~~~
Retra
I'm probably full of crap about this.

If you wrote "a = b/c" it would be silly to complain that this operation 'does
nothing' whenever b == c happens to be true, so by analogy, it's not too
farfetched to think it's useless to write code that does nothing when given a
null object.

On the other hand, multiplication and division are standardized and familiar
operations. Object semantics differ for each kind of object, and it may not
make sense to allow null objects for everything, and if you need one, you can
always implement it later.

So it really depends on what you think the tenets of OOP are, and that's not a
cut-and-dry question.

------
wtetzner
I think the obvious right answer is to not have null in the language, and use
an option type instead. There might be a better solution, but I haven't come
across one yet.

Of course, it's too late for Java now. They have an Optional<T> type, but
removing null from the language would break backwards compatibility. Of
course, that means that a method that returns Optional<T> might return an
Optional<T>, or null, so now you have 2 things to check instead of one :).

~~~
shanemhansen
It's not a full solution, but java has support for nonnullable annotations so
under certain situations the compiler will guarantee that you don't need to
check for null. Backwards compatibility's a PITA.

[http://types.cs.washington.edu/checker-
framework/current/che...](http://types.cs.washington.edu/checker-
framework/current/checker-framework-manual.html#nullness-checker)

~~~
wtetzner
Yeah, I've looked into that, but you have to use their special compiler to
build. I can't find a way to use it in a Maven build that doesn't require the
user to install the checker framework locally.

------
Dewie3
OOP Java-style: nothing comes easy, everything is a pattern.

