Комментарии 50
интересно
скажите, а в java нет типа decimal? в .net (к примеру в C#) есть и он как раз рекомендуется для использования в финансовых операциях.
скажите, а в java нет типа decimal? в .net (к примеру в C#) есть и он как раз рекомендуется для использования в финансовых операциях.
java.math.BigDecimal
как раз long лучше заменить в данном случае на него.
как раз long лучше заменить в данном случае на него.
Зачем на него заменять long, если удалось избавиться от дробной части.
Кроме того, поробуйте выполнить тот же тест что и для double для BigDecimal.
Результат будет таким же.
Кроме того, поробуйте выполнить тот же тест что и для double для BigDecimal.
Результат будет таким же.
ну при его использовании не придется избавляться от дробной части, она там обрабатывается и округляется так, как вам будет нужно
В данном случае использование целочисленного типа упрощает написанный код. Избавиться от дробной части не сложно и делать это нужно в одном месте. Следить же за округлением пришлось бы во всех местах.
Кроме того, long — стандартный тип, поэтому можно использовать стандартные операторы, что повышает читаемость кода.
Кроме того, long — стандартный тип, поэтому можно использовать стандартные операторы, что повышает читаемость кода.
да я понимаю. В большинстве случаев ваша реализация подойдет на 100%. Но если писать более общий класс Money, то лучше, пожалуй, выбрать BigDecimal.
кстати, попробовал выполнить ваш тест с BigDecimal.
результат превосходный и совсем не такой как с double =)
результат превосходный и совсем не такой как с double =)
Я запускаю следующий код:
Результат такой же как с double.
BigDecimal val = new BigDecimal( 0.00 );
for (int i = 0; i < 10; i++) {
val = val.add( new BigDecimal(0.10) );
}
System.out.println( val.equals( new BigDecimal( 1.00 ) ) );
* This source code was highlighted with Source Code Highlighter.
Результат такой же как с double.
1. сравнивать надо их через compareTo()
2. создавать лучше через BigDecimal(String val)
вот так попробуйте
BigDecimal result = new BigDecimal(«0»);
for (int i = 0; i < 10; i++){
result = result.add(new BigDecimal(«0.10»));
}
System.out.println(result.compareTo(new BigDecimal(«1»)));
2. создавать лучше через BigDecimal(String val)
вот так попробуйте
BigDecimal result = new BigDecimal(«0»);
for (int i = 0; i < 10; i++){
result = result.add(new BigDecimal(«0.10»));
}
System.out.println(result.compareTo(new BigDecimal(«1»)));
Жаль, что в Java нет перегрузки операторов. Как-то уныло вызывать всякие subtract…
там и правда нет много «синтаксического сахара», который придумали в других языках. Но в этом есть и своя прелесть — объекты, методы, чистый ооп. Никаких свойств, делегатов, событий и перегрузки операторов.
Знаете — это как пользоваться утилитами через UI или консоль. Есть любители и того и другого.
Знаете — это как пользоваться утилитами через UI или консоль. Есть любители и того и другого.
Не соглашусь со сравнением. GUI (именно так, консоль — тоже UI) и консоль — разные интерфейсы, разные способы доступа к одинаковым функциям. А наличие делегатов и перегрузок и их отсутствие — это именно наличие и отсутствие функций, которым, кстати, никто не заставляет пользоваться. Грубо говоря, не нравится — не ешь.
Это в Java-то чистый ООП? Cкажите-ка, переменная типа int — это объект или нет?
объект
И у него, наверное, есть методы, состояние и прочие обязательные признаки объекта? И какого же он класса?
PS. На всякий случай: что такое autoboxing я знаю, и это совсем-совсем другое.
PS. На всякий случай: что такое autoboxing я знаю, и это совсем-совсем другое.
Не стану утверждать наверняка (не было времени проверить), но ИМХО, было бы глупо реализовывать примитивные типы не как объекты в языке, в котором все остальное реализовано как объекты, даже сами классы являются объектами класса Class. Другое дело, что для программиста примитивные типы не выглядят как объекты. Синтаксический сахар это называется, вроде?
Ну, во-первых, примитивные типы были введены, как оптимизация.
Во-вторых, про «объекты в языке» (наверное, имелось в виду «объекты с точки зрения VM»?) vs «объекты для программиста» — это даже интересно. Как по вашему, для кого придумывается язык программирования, для программиста или для компьютера? Чтобы кому было удобнее? Или поставлю вопрос даже более широко — для кого придумывался ООП, для программиста или для компьютера? И даже если примитивные типы трактовались бы VM, как объекты (на всякий случай уточню, что это не так), то меня, как программиста, это совершенно не волновало бы (в первом приближении) — потому что я не могу с ними работать, как с объектами. И чтобы хотя бы частично компенсировать это, и была придумана подпорка под названием autoboxing (которая, кстати, в отличии от «объектности с точки зрения программиста», является в чистом виде синтаксическим сахаром).
Ну и в-третьих, относительно синтаксического сахара — возможно, мне показалось, но у меня создалось впечатление, что вы использовали это словосочетание в пренебрежительном смысле — так ли это? :-)
Во-вторых, про «объекты в языке» (наверное, имелось в виду «объекты с точки зрения VM»?) vs «объекты для программиста» — это даже интересно. Как по вашему, для кого придумывается язык программирования, для программиста или для компьютера? Чтобы кому было удобнее? Или поставлю вопрос даже более широко — для кого придумывался ООП, для программиста или для компьютера? И даже если примитивные типы трактовались бы VM, как объекты (на всякий случай уточню, что это не так), то меня, как программиста, это совершенно не волновало бы (в первом приближении) — потому что я не могу с ними работать, как с объектами. И чтобы хотя бы частично компенсировать это, и была придумана подпорка под названием autoboxing (которая, кстати, в отличии от «объектности с точки зрения программиста», является в чистом виде синтаксическим сахаром).
Ну и в-третьих, относительно синтаксического сахара — возможно, мне показалось, но у меня создалось впечатление, что вы использовали это словосочетание в пренебрежительном смысле — так ли это? :-)
Неременная типа int — это НЕ объект. Но умеет прикидываться объектом когда надо посредством autoboxing.
не унывай
Может быть, это и не так плохо. Есть много противников перегрузки операторов.
Об этом подробно написано в википедии.
Об этом подробно написано в википедии.
у меня сложилось впечатление, что Фаулер написал целую главу по мотивам вашего поста. а Кент Бек так и вообще полкнижки.
currency != null?! Спокойнее, спокойнее :)
Этот код сгенерирован IDEA. Я сам бы до такого не додумался.
Идея часто подсказывает оптимизации, которые лучше не использовать.
Я бы наверное как-то так написал:
:)
if ((currency == null) != (money.currency == null) || !currency.equals(money.currency)) return false;:)
Я не проверял очень простые методы.
Метод CompareTo тоже простой. В нем вред ли возникнет ошибка, но я все же проверил один вариант.
Некоторые предпочитают проверять все функции. Бек, по-моему, как раз за это.
Другие же, например Фаулер, считают, что проверять элементарные функции не нужно.
Я считаю, что написание полных тестов занимает слишком много времени, что не окупится.
Тест можно поправить, если обнаружится глюк. Многие ошибки выявятся функциональном тестированием.
Метод CompareTo тоже простой. В нем вред ли возникнет ошибка, но я все же проверил один вариант.
Некоторые предпочитают проверять все функции. Бек, по-моему, как раз за это.
Другие же, например Фаулер, считают, что проверять элементарные функции не нужно.
Я считаю, что написание полных тестов занимает слишком много времени, что не окупится.
Тест можно поправить, если обнаружится глюк. Многие ошибки выявятся функциональном тестированием.
специально для работы с деньгами в Java создавали BigInteger, а вообще советую познакомиться с org.jscience.economics.money в рамках интересного проекта Javolution
Много кода из ничего. Одна из черт, за которые не люблю Джаву.
отличная идея постить на хабре результаты своего творчества. Хотите похвастаться своим кодом — идите на sf.net хотя бы…
Удивительно, как много строчек кода нужно написать для реализации фигни.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Класс Money