Null Object Pattern – Pattern or Antipattern
.NET February 13th, 2009The essence of polymorphism is that instead of asking an object what type it is and then invoking some behavior based on the answer, you just invoke the behavior. The object, depending on its type, does the right thing.
from http://sourcemaking.com/refactoring/introduce-null-object
The basis for this pattern is that instead of checking to see if null objects, you create a prototype object, with a “IsNull” property, and instead of checking to see if its null, you would check this property.
To be really honest, im not sure why you would do things this way. This seems like a really convoluted way of basically doing nothing at all. The code samples show that instead of doing object == null, you do object.IsNull. What is the point of that?
This method of doing this is counter intuitive. If the database cannot find the user, why should it return an empty object and set a property to say that it SHOULD be null? If it SHOULD be null, why not set it to null?
In my opinion, this is an antipattern, not a pattern.
August 3rd, 2010 at 2:31 pm
Implementing IsNull is indeed pointless as it doesn’t solve anything. However, I disagree with the database example. Either you expect the database to return something and throw an exception if it doesn’t (e.g. in your DAO code), or you do and handle this in an application-specific way (e.g. return the Guest user object in the above example). The point is that your business code shouldn’t need to bother about checking for nulls.
August 8th, 2010 at 10:29 pm
Pyton – Exceptions should only be used in exceptional circumstances – not finding a user I don’t think is classed as exceptional, as its expected – I would throw an exception if the server couldn’t be found, for example.
ALL code should be checking for nulls – I wouldn’t recommend returning a guest object either – If you call GetUser(“Monty”) – and Monty isnt found, then it shouldn’t return a guest object (The method is called Get User – it should either get the user, or nothing).
You cant throw an exception if the user isn’t found, you cant return a guest or empty object, so the only logical solution is to return null – the DAL’s job is to return the user, or nothing at all. Its the business code’s job to translate a null user object into “No one found”
August 9th, 2010 at 2:18 pm
Couldn’t disagree with you more.
If the user cannot be found (e.g. because incorrect username was entered), this is indeed something exceptional (isn’t supposed to happen with normal application usage), so I think throwing an exception is very appropriate in that case.
Returning a guest user object will indeed not be appropriate in all cases, but it might be in some cases.
You could consider null checking throughout the application code a form of safe programming. However, by doing so you make your code bloated and difficult to maintain (violation of the DRY principle).
You could argue that null checking doesn’t belong in the DAL (if you want to keep your DAL generic in the sense that it is not tailored to particular use-cases or application flows). However, this still is not a good reason to spread null checks thoughout your code. You could handle this elegantly in a seperate layer between your business layer and your DAL.
In short, I think having null checks EVERYWHERE in your code is bad. Having it in one place and one place only is good (whether this is in the DAL or some layer above that).
November 23rd, 2011 at 10:38 am
If you read the entire article you will see that the isNull-method is later removed in a refactoring step leaving only the simple call to getName.
However, I would argue that returning NullObjects are both a blessing and a curse (pattern/antipattern if you will). On one hand it is good to never have to worry about a method return breaking execution but on the other hand it may lead to unexpected side-effects as demonstrated with the infinite loop seen in this video:
http://www.youtube.com/watch?feature=player_detailpage&v=hp1Y9bhail8