I personally use the Drink.NULL or Drink.NONE or whatever pattern.

Because returning a Drink object instead of null means that usually I don’t need to check post conditions and certainly not immediately on return. If, on the other hand, it really is bad that no non-null Drink could be returned an exception is required.

Drink.NULL just needs to have a reasonable toString() etc. and in general behave like a Drink.

-Anders

I’ve seen Null object pattern versions of Value Objects before (ie: Money, Date, etc). You have a isNull method in the case that you want to ask whether or not you have a value. For instance, there may not be an acceptable default value for a Date, so you can’t prevent it from being null. The NullDate class would return true for isNull so I can detect that. Interally, it’ll just be doing a “return value == null”

@Bernd

I agree, the precondition approach has it’s issues - I favor it because of it’s readability and simplicity. As far as preparing for the abuse of the api - well, that’s an issue with having a getDrink() method at all.

a) you still need to prepare for abusive usage of the API - i.e. somebody is calling getDrink() without checking the money, the operating temperature, the maintance state (and other) preconditions.

b) in a multi threaded environment some moethods tends to be atomic so you do not have to hold a lock over multiple invocations. In this scenario a pre condition check might not be valid anymore unti you get to the getter. Somebody stolen your can.

Slightly off topic but please could you expand on the code behind the isNull() method.

Thx.
Bill