It seems to me that the essence of this idea is that you attack a problem in stages, and that each stage should have completely prepared you for the next.
That's where the confidence comes in; you can move forward knowing that your assumptions will hereafter always apply.
Upvote for NullObject pattern -- by far my favorite pattern. Unlike most 'Design Patterns', this is a useful and non-obvious idea no matter what language you work with.
Well, hardly regardless of language--using the Maybe monad is more elegant in Haskell, for example. The beauty there is that your functions don't need to ever worry about getting null input (pronounced Nothing in Haskell), and you can trivially compose functions that possibly return Nothing with functions that don't.
Also, I'm not really sure how a pattern like this would work in Java, although this could just be because my Java is (thankfully) going rusty.
Good point -- I agree that pattern matching and monads are a more general solution to the Null Object problem.
As for Java -- http://www.cs.oberlin.edu/~jwalker/nullObjPattern/ has examples. But the case of the empty linked list is stretching it a bit. Somehow it seems to me you ought to be able to have a regular linked list where the "nothing" behaviour did not need a whole other class.
I usually explain Null Object like this:
Think of a website where you have users who might be logged in or not. A naive way to express this would be that, if the user is not logged in, your getUser() method returns null.
But then you have to keep testing for null, over and over again, before you can do anything with the user. And the user-is-null case is suspiciously similar to user-is-not-authorized-to-do-this-thing.
Solution: make a hierarchy where there's an abstract User class, concretized by NonLoggedInUser and LoggedInUser. The NonLoggedInUser returns false for all isAuthorizedTo().
Now you always have a User, it's just that sometimes that User does "nothing". So you just ask if user.isAuthorizedTo('doTheThing').
That's where the confidence comes in; you can move forward knowing that your assumptions will hereafter always apply.
Upvote for NullObject pattern -- by far my favorite pattern. Unlike most 'Design Patterns', this is a useful and non-obvious idea no matter what language you work with.