d
Автор переупростил пример в ущерб здравому смыслу
double -> BigDecimal
amount -> много разных amount
date -> много разных date не только с типом LocalDate
Size: a a a
2020 March 06
AK
есть ещё в помощь прям специализированный
https://docs.oracle.com/javase/8/docs/api/java/util/Currency.html
но пробелмы тут нет никакой нет, так как это пример
https://docs.oracle.com/javase/8/docs/api/java/util/Currency.html
но пробелмы тут нет никакой нет, так как это пример
RT
потом неопытные разработчики это читают и пишут такой код, ведь оно же ораклом рекомендовано)
AK
потом неопытные разработчики это читают и пишут такой код, ведь оно же ораклом рекомендовано)
у них должен быть помидор или лид, который всё это понимает и следит. если неопытные разработчики сами по себе катают вещи связанные с деньгами и иные критичные участки, тот тут уже другого уровня проблемы
A
потом неопытные разработчики это читают и пишут такой код, ведь оно же ораклом рекомендовано)
Вот это кстати реально проблема. Сколько раз встречал аргумент, что так было написано в книге. И люди непонимают, что примеры в книга это не идеальный, готовый к продакшену код, а всего лишь пример...
И у опытных разработчиков кстати тоже встречал такое)
И у опытных разработчиков кстати тоже встречал такое)
PD
Ну, с деньгами все не просто вообще, да. Money не всегда хорошее решение.
YB
double фу-у-у-у
PD
Ну, есть системы, где деньги в double - и работают (как-то).
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
YB
Ну, есть системы, где деньги в double - и работают (как-то).
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
Если это системы финансового прогнозирования какого-нибудь, то скорости ради можно. Но если это бухгалтерия, то стоит спросить, за чей счёт невязки будут устранять.
СС
Ну, с деньгами все не просто вообще, да. Money не всегда хорошее решение.
кстати да, мы в свое время от money в итоге отказались в MS SQL, потому чтоб ыли нюансы
PD
Если это системы финансового прогнозирования какого-нибудь, то скорости ради можно. Но если это бухгалтерия, то стоит спросить, за чей счёт невязки будут устранять.
Не знаю. У меня то всегда свой класс Money (вернее аккуратная обвязка вокруг joda-вского, а сейчас еще чей-то, не помю уже чей)
PD
Но BigDecimal в стандарте языка, конечно, облегчает жизнь.
СС
смех смехом пока вы не начинаете умножать и делить - всякие НДС и районные коэффициенты... и там вопросы по точности возникают - когда у вас сумма НДС по этапам не бъется с НДС от суммы договора 😊
YB
кстати да, мы в свое время от money в итоге отказались в MS SQL, потому чтоб ыли нюансы
Money неуправляемый тип. deciaml и numeric, т.к. есть места, где налоги надо считать до сотых копейки, а платить до копеек.
PD
Да тут многие в курсе. Хм, кстати, интересно, как по отраслям разделяется чатик.
PD
Money неуправляемый тип. deciaml и numeric, т.к. есть места, где налоги надо считать до сотых копейки, а платить до копеек.
Все еще хуже - иногда и копеек нет, иногда их три знака после запятой. И, о счастье, уже нет старых английских фунтов!
S
Да тут многие в курсе. Хм, кстати, интересно, как по отраслям разделяется чатик.
опрос бы
AK
Ну, есть системы, где деньги в double - и работают (как-то).
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
Но вообще фигня, конечно.
Кстати, интересно, во всяком финтехе на ноде деньги как реализуют )
либами скорей всего, или вокруг BigInt пляшут
PD
Нужно понять, какие пункты в опрос вставить.
Финтех, гейминг, телеком, веб, энтерпрайз, авионика, нефтянка, что еще?
Финтех, гейминг, телеком, веб, энтерпрайз, авионика, нефтянка, что еще?
PD
либами скорей всего, или вокруг BigInt пляшут
Так вроде встроенного BigInt там нет, нужно внешние библиотеки цеплять, а они вряд ли быстрые.