Comments 9
Почему бы не использовать вместо сырого BigDecimal более удобную обертку, которая еще и хранит информацию о самой валюте - Moneta (JSR 354) - Baeldung
А почему не используете операторы котлина? Методы BigDecimal превращают в нечитаемую кашу даже самую формулу. Именно поэтому у вас в коде комментарии с формулой.
Все куда проще, если для написания бизнеслогики использовать языки, специально для этого предназначенные. В частности, имеющие нативные типы данных с фиксированной точкой (при описании переменной сразу указывается разрядность и количество знаков после запятой).
А справочник валют обязательно содержит количество миноритарных единиц - например, японская йена, итальянская лира, испанская песета, португальский эскудо вообще не имеют миноритарных единиц. А оманский реал, тунисский и бахрейнские динары содержат по 1000 миноритарных единиц...
Соответственно, расчеты ведутся в миноритарных единицах, а представление - в мажоритарных в соответствии с количеством миноритарных по справочнику валют.
не ну это смешно , ожидал о самой большой проблемы , это консистентность данные при Lazy Taskax с фронта , а тут... копания в пикселях
Помню лет 10 назад, при написании биллинга в одном из небольших телеком провайдеров, решал задачу распределения суммы потребления услуги за каждый день, тарификация которой была помесячно. Если делить месячную сумму в лоб, то из-за округления могла быть ситуация, когда сумма за каждый день потребления услуги была меньше или больше на несколько копеек, чем стоимость тарифного плана. В результате решил задачу с помощью написания функции, которая эту ошибку равномерно "размазывала" по всем дням так, чтобы сумма за месяц всегда была одинаковая.
Здравствуйте. Представленные здесь куски кода это Kotlin?
Как работать с деньгами, или денежные суммы в бэкенд-разработке