Consequences of changing a primitive to a Boxed Primitive in a Java Application

Question

I am working on an application in which all performance values for a given item are primitives. However, there is now the possibility that one of these values - Revenue - is not available when adding new data to the system. In these cases we are fine with simply storing/displaying the value for Revenue as 0.00

However, we now also want to be able to add this missing data at a later date (but not overwrite data if present). Rather than adding flags to indicate whether Revenue was actually available when 0.00 was added to the database, it seems obvious to me to change Revenue from the primitive type double to a boxed primitive Double, and allow NULLS for the Revenue column in the db.

There are various places in the application where getRevenue() is called however, and mathematic operations are performed upon the value. Obviously now having the potential for getRevenue() to return null could cause major problems. As I mentioned though, we are perfectly happy to present Revenue as having a value of 0.00 in the cases where there is no value present.

So, it seems like an obvious solution would be to update the getRevenue() method to return the value, or 0.00 in the case of the value being null. And to add a new method getRevenueDB() which returns the true value of Revenue, including null. This method would only be called when accessing the value to add to the db.

How does this seems as a solution? It shouold work, and is quick. But does this seem a horribly dirty solution, for which there is a better option available?

All comments are much appreciated!

Answer 1

You effectively have two clients, some who need to see NULLs some who explicitly must not see nulls.

If it really is the case that it makes business sense to convert "Don't Know" to "Zero" then I think it's valid to have two different accessors.

I might choose a different name that getXxxxDb() for example getXxxxxOrNull(), my reasoning being that it's conceivable that it's not only the Db that will care eventually if it's null,

Answer 2

Representing "no value" as null is the correct thing to do.

The alternative implementation is to insert null checks after every call to getRevenue() where it is necessary, which is also ok. Depends whether you want your additional complexity in your model or service layer.

Answer 3

What about keeping the Revenue column as not null and storing it as a zero when you have an empty/missing Revenue to store? You may even be able to do this at the database level with a trigger or a default value.