http://www.guj.com.br/posts/list/5.java JForum - http://www.jforum.net http://www.guj.com.br/prepost/139018/747893/valores-monetarios http://www.guj.com.br/prepost/139018/747893/valores-monetarios GMT
bom.. ai vai depender da necessidade do sistema.. a vantagem de se fazer uma classe para isso é que voce estara apto a disponibilizar para ela como por exemplo, conversão de moeda, de forma semântica e correta... mais se for só pra resolver o problema de manter a quantia de dinheiro de um obj Conta por exemplo, só um atributo float já resolve qualquer quantia plausível...]]> http://www.guj.com.br/prepost/139018/748027/revalores-monetarios http://www.guj.com.br/prepost/139018/748027/revalores-monetarios GMT http://www.guj.com.br/prepost/139018/748038/revalores-monetarios http://www.guj.com.br/prepost/139018/748038/revalores-monetarios GMT vlw]]> http://www.guj.com.br/prepost/139018/748158/revalores-monetarios http://www.guj.com.br/prepost/139018/748158/revalores-monetarios GMT vlw[/quote]

O melhor de tudo é usar o padrão [url=http://sergiotaborda.wordpress.com/java/patterns/money/]Money[/url]. Vc não trabalha com numeros decimais e por isso não tem perda por arredondamento.
Money é a forma de fato para trabalhar com dinheiro o resto é gambiarra.]]> http://www.guj.com.br/prepost/139018/748391/revalores-monetarios http://www.guj.com.br/prepost/139018/748391/revalores-monetarios GMT
[quote]Do ponto de vista técnico ha muito tempo que é sabido que tipos numéricos como double ou float não são suficientes para elaborar algoritmos que lidam com dinheiro e, em Java, nos vemos obrigados a usar BigDecimal. Contudo a classe BigDecimal tem as suas peculiaridades que acabam atrapalhando mais do que ajudam porque embora forneçam mecanismos de calculo, não fornece um mecanismo de controle de unidades.[/quote]

Eu posso utilizar a classe BigDecimal sem medo de estar cometendo gambiarras caso eu Não necessite de conversões monetárias??]]> http://www.guj.com.br/prepost/139018/749031/revalores-monetarios http://www.guj.com.br/prepost/139018/749031/revalores-monetarios GMT
[quote]Do ponto de vista técnico ha muito tempo que é sabido que tipos numéricos como double ou float não são suficientes para elaborar algoritmos que lidam com dinheiro e, em Java, nos vemos obrigados a usar BigDecimal. Contudo a classe BigDecimal tem as suas peculiaridades que acabam atrapalhando mais do que ajudam porque embora forneçam mecanismos de calculo, não fornece um mecanismo de controle de unidades.[/quote]

Eu posso utilizar a classe BigDecimal sem medo de estar cometendo gambiarras caso eu Não necessite de conversões monetárias??[/quote]

Nas escala de pior para melhor opção temos

double e float
BigDecimal
Ratio
Money
Money (usando ratio internamente)

BigDecimal é melhor que double pq vc pode representar potencias negativas de 10 sem problemas (ou seja, centavos)
mas ainda é um decimal. Vc será tentado a escrever 1/3 do mesmo jeito e terá uma dizima infinita do mesmo jeito...
só que uma dizima infinita é irrepresentável, mesmo com bigDecimal. E pior que isso, esse valor não é uma quantidade monetária
aceitável. 1/3 dá 0,33 + 0,33 + 0,33 + 0,01 centavos Esta é a divisão correta de dinheiro por um numero inteiro.

Bom, então ai vc usa Ratio. Ratio é um padrão para numeros em que vc utiliza um valor para numerador e outro para denominador nunca fazendo a divisão real até ao fim do calculo. assim 1/ 3 * 3 = 1 sempre. Vc não consegue isso co double ou float nem bigdecimal.

Mas ratio é para numeros, não dinheiro. Não ha associação à moeda.
Ai vc usa Money. Preferivelmene com ratio internamente para ter calculos mais exatos (ou seja, fazendo menos divisões)

Mesmo quando a moeda é sempre a mesma Money tem vantagem por sem mais fortemente tipado. Numeros podem ser qq coisa, Money só pode ser dinheiro. um metodo chamado calculaJuro(Money) é auto-explicativo. Isto melhora imensamente a clareza do seu codigo e impede erros.

enfim, o ponto não é se é gambiarra ou não. nenhum deles é gamb. O ponto é seguir o principio que diz que vc deve sempre usar o melhor tipo possivel. É mesmo principio que obriga vc a usar numeros em vez de string e string em vez de array de char...

O tipo "dinheiro" quando não é bem modelado causa muitos problemas porque vc começa a perder centavos sem perceber e isso causa prejuizo enorme porque em 100 transações diárias (que é pouco) vc perde 1 unidade. em 356 dias vc perde 356 unidades, e assim vai.

O golpe final do padrão money sobre os outros é o conhecimento do dominio.
Porque o objeto conhece a moeda, ele sabe quantas casas decimais existem na moeda. (nem todas as moedas têm 2 casas decimais como o real, o yen, por exemplo, não tem nenhuma). Isto permite que ele converta qq decimal em um inteiro e depois de volta.
Então quando vc cria o objeto vc passa um valor decimal (utilizando uma String e nunca um double) , mas ele faz as contas com inteiros - muito mais rápido e sem problemas de arredondamento. No fim ele converte de volta para um decimal.

Dê uma olhada [url=http://middleheaven.wordpress.com/toolboxes/quantidades-e-medidas/money-toolbox/]como se pode usar o money[/url] e um exemplo de[url=http://www.google.com/codesearch/p?hl=pt-BR&sa=N&cd=10&ct=rc#fxMOVdP_UqM/trunk/src/main/java/org/middleheaven/quantity/money/Money.java&q=money%20package:http://middleheaven%5C.googlecode%5C.com&l=13] implementação[/url] usando o padrão Ratio.
]]> http://www.guj.com.br/prepost/139018/749195/revalores-monetarios http://www.guj.com.br/prepost/139018/749195/revalores-monetarios GMT http://www.guj.com.br/prepost/139018/751907/revalores-monetarios http://www.guj.com.br/prepost/139018/751907/revalores-monetarios GMT
Vc pode usar o padrão Ratio que falei antes. Já que todas as percentagens são numeros divididos por 100. 88% = 88/100
e 88,99% = 8899/10000 . Co ratio vc sempre trabalha com numeros inteiros durante o máximo de tempo possivel delegando a adivisão final apenas para o fim do calculo. É a forma que se usa na matemática onde se usam frações para não calcular a divisão explicitamente.]]> http://www.guj.com.br/prepost/139018/757869/revalores-monetarios http://www.guj.com.br/prepost/139018/757869/revalores-monetarios GMT