Null Object Design Pattern and Integer? 1

[haslo]

It seems you can't apply the Null Object Design Pattern to uses of the Integer wrapper class, because it's final...

Any solutions that let us avoid the dreaded

object==null

test (and the resulting special handling whenever we need a toString() or something) which don't use a Proxy class?

www.haslo.ch​

 

[stefanwagner]

The neutral element for multiplication is 1 while the neutral element for addition is 0, so I don't think there is a lean solution.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[haslo]

Hm, thanks :-/ A pity, since in a database application like ours it actually makes a difference whether it's a neutral element or actually not defined...

I think we'll revert to using proxies then anyway, at the cost of losing autoboxing / unboxing

www.haslo.ch​

 

[stefanwagner]

All database I know distinguish between empty=undefined and 0.
Using an Integer which is either =null or =new Integer (1) keeps this difference available.

If you create your own Wrapper around Integer like 'NilableInt', which contains an Integer, and hides the Integer-object, you loose the good integration for the Integer-class, especially auto-boxing.

But object==null needn't be dreaded. If distincting between 0 and empty has some meaning, you need to handle it in some way.

I.e. calculate the average number of childs from 5 Persons:
avg:{3, 0, 1, -, 2} = 6/4
Would a NilInteger help here in some way?

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[haslo]

No, it wouldn't help with regular int operations. It would however help with toString() (just returning an empty String), and generally avoid NullPointerExceptions in cases where null objects specificially don't need special handling. The application we're thinking of refactoring consists of several hundred classes, each of which is several hundred lines long, and only roughly half the data handling routines actually need to know what's inside an object, be that null or any other value doesn't interest them at all - and they'd like to be able to handle "null" objects like everything else too. That's what the design pattern I linked is all about

We ended up deciding on a Proxy object anyway though, because this can handle not only the design pattern we want, but also additional computing that data objects could be responsible for themselves. Like conversions, ID objects (which we actually already have), metadata, the likes.

The first implemention we had actually used null object references, however always handling these specially, even in the many cases where the content is of no interest, lead to many problems in development, always thinking of having to check for null is a nice idea but doesn't really work out in the long run...

And the main reason why we're thinking about refactoring is because the data is always saved as String objects or null, with the 3 magic values "", "---" and "NaN" being equivalent to null, thus we always had to check for such a null thing like this:

if (!(object == null || object.equals("") || object.equals("---") || object.equals("NaN"))

The new implementation we'll make (or not, due to time restraints) will be somewhat like this, with added methods of course:

public interface NullObject
public interface DataObject

public class IntegerObject implements DataObject
public class NullIntegerObject extends IntegerObject implements NullObject

The same for Boolean, Double, String and our own ID type (with integrated resolving of foreign key references) will make the above check much easier, should it be necessary at all, and unnecessary in the aforementioned cases where the actual data is completely irrelevant.

if (!object instanceof NullObject)

www.haslo.ch​