Null object design pattern Vs null object check

Question

Why null object design pattern is better than null object check. If we look at the memory footprint in null object design pattern we create a new dummy object of same type. Which show if we have object of big size and large number of nullable objects in search query, this pattern will create that much number of null object which will occupy more memory than a simple check which for null which my cost ignoreable delay in performance.

Null Object design pattern

Answer 1

The whole problem with null is that if you try to access a null value the application will throw a NullPointerException and abort.

To reduce the number of class NullXXX in this null object design pattern (its actually just the factory design dattern, not a pattern itself) you could make a static final NullCustomer which is always returned.

In Java 8 you can use the Optional approach in order to tell when a function does not always return values. This approach does not force you to create arbitrary null classes which pollute the overall structure (consider may have to refactor those null classes, too).

Eclipse and IntelliJ also offer compile time annotations @Nullable, @NonNull which give compiler warnings when accessing potential null objects. However, many frameworks are not annotated. IntelliJ therefore tries to discover those potential null accesses with static analysis. Beside low adoption of this approach IntelliJ and Eclipse use their own annotations (org.eclipse.jdt.annotation.NonNull, com.intellij.annotations.NotNull) that those are not compatible. But, you can store the annotations outside of the code which works in IntelliJ. Eclipse want to implement this in the future, too. The problem is that there are many frameworks providing this feature giving you many different annotations doing the very same. There was JSR-305 which is dormant. It'd provide an annotation in javax. I don't know the reason why they did not pushed this further.

Answer 2

The major advantage of using Null Object rather than null is that using null you have to repeat checks of whether that object is indeed null, particularly in all methods that require that object.

In Java 8, one will have to do:

Object o = Objects.requireNotNull(o); //Throws NullPointerException if o is indeed null.

So, if you have a method that constantly pass the same object into various method, each method will need to check that the object received is not null before using it.

So, a better approach is to have a Null Object, or Optional (Java 8 and higher) so that you don't need to do the null check all the time. Instead one would:

Object o = optional.get(); //Throws NullPointerException if internal value is indeed null.
//Keep using o.

No (really) need for null checking. The fact that you have an Optional means that you might have a value or none.

Null Objects have no side effects because it usually does nothing (usually all methods is an empty method) so there is no need to worry about performance (bottlenecks/optimization/etc).

Answer 3

The main difference (and probably the advantage) of this pattern is distinctness. Think about the following method definition:

public static int length(String str);

This method calculates length of given string. But could argument be null? What will the method do? Throw exception? Return 0? Return -1? We do not know.

Some partial solution can be achieved by writing good java doc. The next and a little bit better solution is using annotations JSR305 annotattion @Nullable or @NotNullable that however can be ignored by developer.

If however you are using Null object pattern (e.g. Optional of guava or java 8) your code looks like the following:

public static int length(Optional<String> str);

So developer must care about wrapping his string into Optional and therefore understands that argument can be null. Attempt to get value from Optional that contains null causes exception that does not always happen when working with regular null.

Obviously you are right that using this pattern causes some additional CPU and memory consumption that however are not significant in most cases.

Answer 4

Suppose you have something like this:

private SomeClass someField;

void someMethod() {
  // some other code
  someField.method1();
  // some other code
  someField.method2();
  // some other code
  someField.method3();
}

Now suppose that there are valid use cases when someField can be null and you don't want to invoke its methods, but you want to execute the other some other code sections of the method. You would need to implement the method as:

void someMethod() {
  // do something
  if (someField != null) {
    someField.method1();
  }
  // do something
  if (someField != null) {
    someField.method2();
  }
  // do something
  if (someField != null) {
    someField.method3();
  }
}

By using Null object with empty (no-op) methods we avoid boilerplate null checks (and the possibility to forget to add the checks for all of the occurrences).

I often find this useful in situations when something is initialized asynchronously or optionally.