Null Object - design pattern

Joshua Bloch in his excellent book Effective Java (2nd Edition) gives advice that you should never return null collection/map/array from your code i.e. instead of such code:

public List<String> returnCollection() {
  //remainder omitted
  if (/*some condition*/) {
    return null;
  } else {
    // return collection
  }
}

you should always use this pattern:

public List<String> returnCollection() {
  //remainder omitted
  if (/*some condition*/) {
    return Collections.emptyList();
  } else {
    // return collection
  }
}

This basically prevents caller of your code to get NPE while trying to do things like this:

if (obj.returnCollection().size() > 0) {
// remainder omitted

Robert C. Martin in his book Agile Software Development, Principles, Patterns, and Practices gives another very similar pattern but related to ALL objects, not only to collections/maps/arrays. This design pattern is called Null Object.

Here is the example - let's assume that you have an application that check whether the user is authenticated:

public class User {
  private String username;
  private boolean authenticated;
  // remainder omitted

  public boolean isAuthenticated() {
    return authenticated;
  }
  // remainder omitted
}

and the code that returns the reference to the User object looks like this:

public User getUser() {
  if (/*some condition*/) {
    return user;
  } else {
    return null;
  }
}

This way the code that checks whether our user is authenticated should look like the following snippet:

if (obj.getUser() != null && obj.getUser().isAuthenticated() {
  // allow
}
// remainder omitted

Checking whether the object is null is not only a boilerplate code but it can also give you a lot of bugs e.g. if you forget to check whether the object is null.

And here the Null Object can help you:

public class NullUser extends User {
  
  public static final NullUser INSTANCE = new NullUser();

  public static NullUser getInstance() {
    return INSTANCE;
  }

  @Override
  public boolean isAuthenticated() {
    return false;
  }

  private NullUser() {
  }
}

plus:

public User getUser() {
  if (/*some condition*/) {
    return user;
  } else {
    return NullUser.getInstance();
  }
}

plus cleaner client code:

if (obj.getUser().isAuthenticated() {
  // allow
}
// remainder omitted

I find this pattern very useful and really helpful. With this pattern you can really save yourself a lot of NPEs.

Still the question is whether User should be a class or an interface and then whether NullUser should extend the base class or implement the user's interface. But I will leave this decision for your consideration.

What do you think about Null Object pattern?

PS. Example I presented is not necessarily applicable in the real systems - it is here just to depict design pattern's idea. Please don't treat provided code as a solution (I can think of many improvements/changes to it depending on the context by myself) - think about it at the pattern level - not the code level.