|
|
Re: Offensive Coding
|
Posted: Sep 7, 2006 10:45 AM
|
|
> <pre>
> public String [] getParameters() {
> String [] result = new String[intParms.length];
> for(int n = 0; n < intParms.length; n++) {
> result[n] = "parameter " + intParms[n];
> }
> return result;
> }
>
> </pre>
>
> <p>If we don’t have any parameters, we return an empty
> array. The empty array is an example of a null object..
> an object which gracefully handles an exceptional case.
> Now that we're always returning a valid array, there's
> s one less possible error.</p>
It's easy to fix this situation when returning things like collections. That's because a "null object" for a collection is very easy to create - it's just a collection with no elements in it. Similarly for Strings, a null object is easy - it's just an empty string.
However, having read Bobby Woolf's paper on the NullObject Pattern some years ago, one of the key things I took away from it is that it can often be very difficult to create a null object implementation for many types of objects. Sometimes this is because, as Bobby's paper cited, it can be difficult to define exactly what the null behavior is. But sometimes also, some objects really don't lend themselves well to being null objects.
For example: look at this code:
<java>
public class Database {
public Record findRecord(Key key, Object keyValue) {
...
}
}
</java>
What exactly are we to return if the Record is not found on the database? The implication from this article is that we should return a NullRecord. But it's very difficult to implement "null" behavior on a Record. Most likely the Record object has methods to retrieve the data values for various columns, e.g.:
<java>
public interface Record {
public String getStringValue(String columnName);
public int getIntValue(String columnName);
...
}
</java>
But there's no way, for example, to return a "null int" from the getIntValue method.
And even for the case of getStringValue, I think it would be misleading to the developer to return any value, even the empty string. Returning an empty string would imply to the developer that the record was found, and that the value contained in that column was the empty string. That's obviously not correct, but there'd be no way using a NullRecord to distinguish between a record not found and a record containing nothing but empty strings for its values.
What else should it do then? Throw exceptions on every getXXXValue method? Bad design, IMO. You shouldn't have to wait until you start trying to query a DB record to find out that it wasn't found. You should have found out on the Database.findRecord() call.
But again, how do we indicate "not found" from the findRecord call? Since null object doesn't seem workable here, and we're trying to avoid returning nulls, then the only other option I can see is to throw an exception. But frankly, that's a poor design choice too, IMO. Having a record not be found is a very legitimate outcome of a find operation, IMO, and so you should not throw an exception - indicating an exceptional or error outcome - in a case like this.
Frankly, IMO, returning null is the right thing to do in a case like this - and probably in numerous other cases too for the same reasons.
Thoughts anyone?
DR
|
|
Previous Topic
