Null Object Pattern to avoid Null checks?

Question

Lately I have come across Null Object design pattern and my colleagues say it can be used to do away with the null pointer checks that are encountered throughout the code.

for e.g suppose a DAO class returns information on Customer (in a value object called CustomerVO). My main class is supposed to extract the firstName and emailId and send email to customer.

...
CustomerVO custVO = CustomerDAO.getCustomer(customerID);
if(custVO != null) { // imp, otherwise we may get null ptr exception in next line
     sendEmail(custVO.getFirstName(), custVO.getEmailID());
}
...

This is very simple example, but such null checks can quickly spread throughout your code based on the complexity of the value objects.

I have two issues with null check, - they tend tmake the code ugly and hard to read - lesser experienced developers put unnecessary null checks when in fact they are supposed to throw exceptions. for e.g. in above code, it would be better to throw exception from getCustomer() itself because if its not able to find customer info for given CustID, it indicates the CustID was invalid.

okay, coming back to null object pattern, can we use a 'null' CustomerVO object to hide the null check?

CustomerVO {
   String firstName = "";
   String emailID = ""; 
}

Don't it would make sense. what do you think?

And what are the things you follow to minimize null checks in your app.

Answer 1

In this case a null object may be inappropriate since the default may infact hide what is in actuality an exception. If you find yourself having to check to see if your have safe null to perform some other activity the null pattern isn't buying you anything.

As you stated many new developers spend time trying to protect their code from exception situations that are worse then a halting program.

Answer 2

While the null object pattern has it's uses, you're still going to need to make a check here, otherwise you're going to try to sendEmail() to an email address that's the empty string (or you push the check into sendEmail(), which could just as easily check for null).

Where the null object pattern would be really helpful here is if the CustomerVO class implemented the sendEmail() method. then you could simply chain the calls together, since the contract of getCustomer() would ensure that a null reference wouldn't be returned:

CustomerDAO.getCustomer(customerID).sendEmail();

In that case the sendEmail() method would check that its been asked to act on the special 'null object' and simply do nothing (or whatever's appropriate).

Answer 3

Should your getCustomer method throw an exception if the customer is not found, rather than returning null?

The answer, of course, is that it depends: should it almost never be the case that a customer ID does not exist? In other words, is it an exceptional circumstance? If so, an exception is appropriate.

However, in a data-access layer it is often quite normal for something to not exist. In that case, it is better not to throw since it isn't an unexpected, exceptional circumstance.

The 'return a non-null object that has empty fields' is probably not any better. How do you know if the returned object is 'valid' or not without now adding some checking code that is probably worse than the null check?

So, if it might be a normal state that something being fetched does not exist, the null check pattern is probably best. If it is something that is unexpected then having the data access method throw a NotFound exception is probably better.