Is it feasible to create a NullObject for every class? ( with a tool of course )

Question

The NullObjectPattern is intended to be a "safe" ( neutral ) behavior.

The idea is create an object that don't do anything ( but doesn't throw NullPointerException either )

For instance the class defined as:

class Employee {
    private String name;
    private int age;
    public String getName(){ return name; }
    public int getAge()    { return age;  }
}  

Would cause a NullPointerException in this code:

 class Other {
      Employee oscar;

      String theName = oscar.getName(); // NPE

 }

What the NOP says, is you can have an object like this:

 class NullEmployee extends Employee {
      public static final  Employee instance = new NullEmployee(); 
      public String getName(){ return ""; }
      public int getAge()    { return 0;  }
 }

And then use it as the default value.

 Employee oscar = NullEmployee.instance;

The problem comes, when you need to repeat the code for every class you create, then a solution would be to have a tool to created it.

Would it be feasible/reasonable/useful to create such a tool or to use it ( if existed )?

Perhaps using AOP or DI the default value could be used automagically.

Hussar

Answer 1

To me, the Null Object pattern feels like a placebo. A real object and a null object may have completely different meanings, but act very similar. Just like a placebo, the null object will trick you into believing there's nothing wrong, but something could be very wrong.

I think it's a good practice to fail early and fail often. In the end, you'll want to distinguish between a real object and a null object somewhere, and at that point it would be no different from checking against a null pointer.

From the Wikipedia article:

The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.

It won't point out any problems either. Think of what will happen when a null object travels all the way through your application. Then, at some point, your application expects certain behavior from the object, which the null object implementation fails to deliver. At that point your application may crash or enter an invalid state. You'll have a very hard time tracing the origin of the null object. A null pointer would have thrown an exception right at the beginning, drawing your attention directly to the source of the problem.

The only example the Wikipedia article gives, is that of an empty collection instead of null. This is a very good practice, but a lousy example of the null object pattern, because it's dealing with a collection of objects, instead of a single instance.

In short, I'm sure it's feasible to create null object implementations for all your classes, but I strongly recommend against it.

Ivar

The null object pattern is often good for immutable types, but is generally bad for mutable ones. The reason is that having every ImmutableFoo reference default to the same instance does not create any relationship among the ImmutableFoo references. By contrast, having every MutableFoo reference default to the same instance would bind all such references together in a way that wouldn't really make sense. – Cozza

Answer 2

I am not sure this is a good idea. A "nullObject" may be useful and make perfect sense in some cases, but having this for every class is an overkill. Especially because this could potentially make some bug (or gaps in analysis) very hard to diagnose.

Also, what about 3rd part libraries that return new objects? Would you put some kind of "interface" in front of these so that in case they return null you will substitute an appopriate flavour of nullObject?

You mention that you are trying to automate this - wouldn't some cases require an actual design decision to return an appropriate value? I.e., suppose you have an Image object, and it returns a "ImageType" (an Enumeration for .gif, .jpg etc.)

In this case, the ImageNullObject should return... "IMAGETYPE.GIF"? "IMAGETYPE.UNKNOWN"? Null?

Mammet

Answer 3

I think you are just begging to push the error conditions down a layer.

When an application asks for an object, and it is null, then you need to deal with that condition, not just hope it is ok. If the object is null, and you try to use it, you will get errors, so why force all that error checking on the rest of the code?

Loreleilorelie

Not always a bad practice. Sometimes it doesn't matter. Example. You have a Request class, it has an optional property, Approver, which contains a null or a Person object. When saving the Request, you'll have a line of code that references Approver.ID. Approver could be null, and you'd have to check, and replace it with a default. This could be happening on dozens of objects that reference an optional Person. When it doesn't matter, let the code carry on indifferent to whether it's a NullPerson object or a real Person object. When you NEED a real Person, you check the objects type. – Docker

Answer 4

I'd think it would be tricky to autogenerate functional null objects. (You could of course create shells that you then go and fill in the implementation itself).

As a quick example - what is the null functionality for a method that returns an int? Should it return -1, 0, or perhaps some other value? How about something that returns a String - again, is null or "" the correct choice? For methods returning some other class - if it's one of your own classes then presumably you could use the Null Object for that class, but how would you access it? Perhaps you could make every class you write implement some interface with an accessor for the null object, but is it worth it?

Even with methods that return void, it's not always the case that the null functionality is to simply return. Some classes, for example, might need to call a method on a parent/delegate object when they've done their own thing (which in this case would be a no-op) in order to preserve the invariants of the class.

So basically - even to implement "null" behaviour, you have to be able to infer what this behaviour is, and I expect this is far too advanced for a tool to do itself. Perhaps you could annotate all your methods with something like @NullReturns(-1), and have a tool pick these up and form the null object implementation, but even that won't cover every situation and you may as well write the object directly instead of writing all its functionality in annotations.

Redneck

Answer 5

Except for testing, I generally call this type of concept coding for Slop. It's the opposite of fail-fast, you are postponing any chance of locating a state you did not code for.

The main point here is why is it possible for your object to return a value that's not in the method's contract? When you designed and coded the method's contract, you either said it could or couldn't return null, right? So if you can return null, it's important. If you can't return null, it's important.

Also, If the object reference you are using can be null then that's a significant value and you shouldn't EVER be dipping into code that might access that object's methods.

On top of that, use final/constant/invariant variables every chance you get and (at least with OO languages, isolate your data behind a constructor that can insure correct state). If an immutable object correctly sets up it's variables, it's impossible for those variables to return invalid values.

Except for emergency patches and testing I honestly can't see any excuse for this kind of coding except "I don't understand the code and I think this isn't working right but I don't want to try to understand it"--which is not, IMO, a valid excuse for an engineer.

Roundfaced

I'll go replace "javadocs" with "Docs"--it was a bit more than that, thanks for the heads up. – Roundfaced

Answer 6

What I'd like to see would be for a compiler to allow one to define the behavior of a null object with a statically-defined type. For example, if 'Foo' is of class 'bar':

Class Bar
  Dim Value as Integer
  Function Boz() As Integer
    Return Value
  End Sub
  Sub Nothing.Bar() As Integer
    Return -9
  End Sub
End Class

attempting to evaluate Foo.Bar() would yield Foo.Value if Foo is non-null, or else -9. One could achieve some such functionality using extension methods, but that seems a little icky.

Cozza