Comments on: Lesson from Object Bootcamp - The Null-Object Pattern

By: Josh Graham

Josh Graham — Mon, 05 Mar 2007 09:36:26 +0000

Hmmm.

Nate’s example is nice for testing (stub-a-licious). Probably not nice for production code.

Fail fast and NPE if there’s not a useful implementation. Defaulting to a null object seems rather dangerous and makes it harder to find subtle bugs.

Use dependency injection of a “simple” or “does nothing” or “null” implementation is really really what you’re after. It should respond with “situation normal” just like a real implemenation would.

In your scenario, if there was no mail sending aparatus available, the “null” emailer probably should behave like everything was fine. Returning false would indicate something should have happened but didn’t and the code needs to deal with it (Exceptions, anyone?). If you’ve explicitly wired in a “do nothing but be happy about it” implementation then it should return true and the code continues as everything has eventuated as desired.

Perhaps.

By: Nate

Nate — Tue, 27 Feb 2007 22:05:13 +0000

Oh, and on your example: Java isn’t quite that concise, and having a method return it rather than a constant won’t ensure you have only one copy. I think this is what you meant:

public class Email {
public static final Email NONE = new Email() {
public boolean sendEmail(String message) {
return false;
}
};

private String emailAddress;

public boolean sendEmail(String message) {
// send out email using Javamail or something
}
}

By: Nate

Nate — Tue, 27 Feb 2007 21:51:51 +0000

I would replace the ‘never’ with ‘never, except at your module boundary’. Returning a NullObject to someone outside of your module is at least as bad as returning a null. NullObjects are generally quite specialized to exactly the operations you need them to quietly ignore. As soon as someone needs to check for a NullObject or it makes your code complex, you’ve lost.

By: Chris Johnston

Chris Johnston — Tue, 27 Feb 2007 21:13:57 +0000

Good point. And I get to learn something else. I have updated my post and removed the last few bits to reflect your comment. I agree, the point of the pattern is to ensure that you do not need to check what was returned. You can simply assume that the returned object is good and rely on the defaults to prevent any problems.

By: Nat

Nat — Tue, 27 Feb 2007 20:40:43 +0000

The whole point of the Null Object pattern is that you *never* check if the object is null, you just call a method and it does the right thing — nothing if the object is “null” and something if the object is “real”.

E.g. if you have statements like “if (returnedEmailAddress==noEmailAddress) {… ” in your code you are not following the Null Object pattern (or OO design principles) fully. The branches of the if statement should be moved into the appropriate implementors of the Email interface and the explicit conditional replaced by a polymorphic call.