Последствия замены примитива на штучный примитив в приложении Java

Question

Я работаю над приложением, в котором все значения производительности для данного элемента являются примитивами.Однако теперь существует вероятность того, что одно из этих значений - выручка - будет недоступно при добавлении новых данных в систему.В этих случаях нам достаточно просто сохранить / отобразить значение «Доход» как 0,00

. Однако теперь мы также хотим иметь возможность добавить эти отсутствующие данные позднее (но не перезаписывать данные, если они есть).Вместо того, чтобы добавлять флаги, чтобы указать, был ли фактически доступен «Доход» при добавлении 0,00 в базу данных, для меня очевидно, что нужно изменить «Доход» с типа примитива double на коробочный примитив Double и разрешить NULLS для столбца «Доход» в БД.

В приложении есть различные места, где вызывается getRevenue (), и математические операции выполняются со значением.Очевидно, что теперь, когда getRevenue () может вернуть значение null, могут возникнуть серьезные проблемы.Как я уже упоминал, мы очень рады представить «Доход» как значение 0,00 в тех случаях, когда значение отсутствует.

Таким образом, кажется очевидным решением было бы обновить getRevenue ()метод для возврата значения, или 0,00 в случае, если значение равно нулю.И добавить новый метод getRevenueDB (), который возвращает истинное значение Дохода, включая ноль.Этот метод вызывается только при доступе к значению для добавления в БД.

Как это выглядит как решение?Это должно работать и быстро.Но кажется ли это ужасно грязным решением, для которого есть лучший вариант?

Все комментарии очень ценятся!

Answer 1

У вас фактически есть два клиента, некоторые из которых должны видеть NULL, а некоторые явно не должны видеть нули.

Если это действительно так, то имеет смысл преобразовать «Не знаю» в «бизнес»Ноль ", тогда я думаю, что это справедливо иметь два разных метода доступа.

Я мог бы выбрать другое имя, которое getXxxxDb (), например, getXxxxxOrNull (), я полагаю, что вполне возможно, что в конечном итоге не только Db будет заботиться, если он нулевой,

Answer 2

Представление «no value» в виде null является правильным решением.

Альтернативная реализация - вставлять нулевые проверки после каждого вызова getRevenue (), где это необходимо, что тоже нормально.Зависит от того, хотите ли вы получить дополнительную сложность в модели или на уровне обслуживания.

Answer 3

Как насчет того, чтобы сохранить столбец «Доход» как not null и сохранить его как ноль, если у вас есть пустой / отсутствующий доход для хранения? Вы даже можете сделать это на уровне базы данных с помощью триггера или значения по умолчанию.