[Reclamação] Double vs BigDecimal

Programação Java
#1

Antes de mais nada, sou programador java desde 2004.

Eu não acompanho as JSRs da vida, e não sei se está sendo feito algo nesse sentido.
Mas quando é necessário trabalhar com um sistema onde temos muitas operações aritimeticas/monetarias, é impossível usar Double, visto que double tem aqueles problemas de arredondamento (que já foi provado por a+b que não é bem um problema, é assim que é e ponto final). Então quando vocÊ na sua vida profissional se depara com isso descobre o BigDecimal, que funciona do jeito que deve ser.
Até aí tudo bem o complicado é encontrar um código assim:

BigDecimal a = new BigDecimal("5");
BigDecimal b = new BigDecimal("5");
BigDecimal c = a.add(b);

Seria muito mais fácil/legivel assim:

BigDecimal c = a+b;

Agora a pergunta que não quer calar, como o java é a linguagem mais usada no mundo (e não me venham falar de javascript aqui, javascript é uma linguagem auxiliar)
se ainda tem problemas como esse?
Acho que os caras da Sun em seus tempos aureos fizeram muita lavagem cerebral na gente né?

#2

Bom, BigDecimal é um objeto, e em Java não se pode somar objetos (a não ser Strings).

Desculpem-me se eu falar alguma bobagem mas pelo o que eu li, sobrecarga de operadores permitem que você some, subtraia, etc… objetos.

Se isso fosse implementado em Java, com certeza resolveria esse problema.

No momento, o que eu mais gostaria de ver em Java é isso ai.

#3

O problema não está na linguagem, mas, na pessoa que a usa.
Pare de pensar estruturado, comece a pensar orientado a objetos.
No mundo estruturado, sim, seria mais claro, objetivo e ideal que as coisas funcionassem assim

int a = 1 + 1;

Já no mundo orientado a objetos as ações devem ser restritas a métodos, logo

BigDecimal c = a.add(b);

É infinitamente mais elegante e adequado.

E se você acha que java está errada por coisas como esta [quote=Rafael Rossignol](que já foi provado por a+b que não é bem um problema, é assim que é e ponto final)[/quote] por que as coisas são assim.
Se não gosta, crie suas próprias classes, da forma que bem entender. Mas, quando sair dessa visão limitada à programação estruturada, verá que o erro, neste caso, não é do java, nem da falecida Sun, mas teu.

#4

é esse o ponto que eu queria chegar (sei que java não soma objetos a não ser strings e wrappers)
Quando vão fazer a bendita sobrecarga de operadores?
resolveria boa parte dos problemas de lógica de negocio

imaginem que maravilha:

List lista1 = lista2+lista3;
List listaA = listaB-listaC;
BigDecimal z = (x/y).round(2);
#5

[quote=drsmachado]
Se não gosta, crie suas próprias classes, da forma que bem entender. Mas, quando sair dessa visão limitada à programação estruturada, verá que o erro, neste caso, não é do java, nem da falecida Sun, mas teu.[/quote]

Bom, eu não concordo com você.

Não tem a ver com programação estruturada e orientação a objetos, mas sim com legibilidade de código.
Se não fosse assim, groovy não teria criado maneiras diretas de acessar coleções e mapas e também não faria operações de big decimal diretamente

Além do fato, que ao longo dos anos o java foi ganhando facilidades para se escrever código, vide:

for (Objeto obj: lista) {
}

E eu trabalho com fatos, mexa com qualquer sistema fiscal ou financeiro, onde as regras de negocio exijam um pouco de complexidade matematica (só um pouquinho) e verá onde o caos se instaura.
Fora que no mundo real, você tem que conviver com programadores bons ou ruins, quando você não é o patrão, você não tem escolha, tem que mexer no código de trogloditas que com certeza vão usar melhor operadores do que metodos.

#6

[quote=Rafael Rossignol]é esse o ponto que eu queria chegar (sei que java não soma objetos a não ser strings e wrappers)
Quando vão fazer a bendita sobrecarga de operadores?
resolveria boa parte dos problemas de lógica de negocio

imaginem que maravilha:

List lista1 = lista2+lista3; List listaA = listaB-listaC; BigDecimal z = (x/y).round(2); [/quote]
Continua vendo estruturado.
Ou, do ponto de vista de alguém que tem preguiça de usar o CTRL + barra de espaço…
Pois:

List lista1 = lista2.addAll(lista3);
List listaA = listaB.removeAll(listaC);

E quanto ao exemplo referente ao bigdecimal, lembre-se, o número gerado ali possui a estrutura de um double por padrão (ponto flutuante), logo, seria preciso realizar o cast explícito, mesmo para associar o valor da expressão à uma variável float ou int.

#7

@drsmachado
vejo que tem a cabeça bem limitada!

Eu criei um pseudocódigo alí onde você comentou
Eu sei como funciona o java, como eu disse, trabalho com java desde 2004 (programo em java desde 2002)

Não tem porque vocÊ me falar que tenho que fazer cast, pois eu fiz um código de como deveria ser a linguagem, e no meu mundo de imaginação, quem diz se tem ou não que fazer cast sou eu, pois fui EU que imaginei como deveria ser.

Veja, eu não sou contra a orientação a objetos, ela é legal, sou a favor da simplificação da leitura de código, temos que nos preocupar com problemas muito piores do que entender uma soma seguida de divisão. Podemos transformar 10 linhas difíceis de entender em 2 bem mais fáceis e ainda sim o código vai ser tão orientado a objetos quanto o outro.
E o mais importante de tudo, o objetivo final que é o programa funcionar, vai ser conquistado em menos tempo, e a complexidade de manutenção vai ser menor.

#8

[quote=Rafael Rossignol][quote=drsmachado]
Se não gosta, crie suas próprias classes, da forma que bem entender. Mas, quando sair dessa visão limitada à programação estruturada, verá que o erro, neste caso, não é do java, nem da falecida Sun, mas teu.[/quote]

Bom, eu não concordo com você.

Não tem a ver com programação estruturada e orientação a objetos, mas sim com legibilidade de código.
Se não fosse assim, groovy não teria criado maneiras diretas de acessar coleções e mapas e também não faria operações de big decimal diretamente

Além do fato, que ao longo dos anos o java foi ganhando facilidades para se escrever código, vide:

for (Objeto obj: lista) {
}

E eu trabalho com fatos, mexa com qualquer sistema fiscal ou financeiro, onde as regras de negocio exijam um pouco de complexidade matematica (só um pouquinho) e verá onde o caos se instaura.
Fora que no mundo real, você tem que conviver com programadores bons ou ruins, quando você não é o patrão, você não tem escolha, tem que mexer no código de trogloditas que com certeza vão usar melhor operadores do que metodos.[/quote]

O teu melhor argumento é este?
Se você acha que groovy é melhor, sugiro que vá trabalhar com groovy. Puts, o mercado groovy é bem menor que o de java, não?
Aliás, se você usa a falta de capacidade dos programadores para justificar por que seria melhor modificar a linguagem, bem, você parece não entender que é responsabilidade de quem codifica conhecer o código. Se o cara é ruim, demita-o.
Programadores ruins (analistas e outros profissionais também) só existem por que há empresas que prezam pelo baixo salário, acabam preterindo bons profissionais em troca de profissionais ruins (veja bem, profissional ruim é diferente de inexperiente).

Não é por que a população brasileira quase sempre erra a pronúncia e a escrita das palavras problema e cérebro que estas precisam ser alteradas. É o povo que precisa ser educado.

#9

Sobrecarga de operador é um exemplo de polimorfismo portanto eu discordo do argumento que “feriria a orientação a objeto”.

#10

[quote=Rafael Rossignol]@drsmachado
vejo que tem a cabeça bem limitada!

Eu criei um pseudocódigo alí onde você comentou
Eu sei como funciona o java, como eu disse, trabalho com java desde 2004 (programo em java desde 2002)

Não tem porque vocÊ me falar que tenho que fazer cast, pois eu fiz um código de como deveria ser a linguagem, e no meu mundo de imaginação, quem diz se tem ou não que fazer cast sou eu, pois fui EU que imaginei como deveria ser.

Veja, eu não sou contra a orientação a objetos, ela é legal, sou a favor da simplificação da leitura de código, temos que nos preocupar com problemas muito piores do que entender uma soma seguida de divisão. Podemos transformar 10 linhas difíceis de entender em 2 bem mais fáceis e ainda sim o código vai ser tão orientado a objetos quanto o outro.
E o mais importante de tudo, o objetivo final que é o programa funcionar, vai ser conquistado em menos tempo, e a complexidade de manutenção vai ser menor.

[/quote]
Bem, se você imagina, por que não faz com que a sua imaginação saia da abstração e torne-se real?
Se você trabalha desde 2000 e antigamente com a linguagem já deve saber que ela provê recursos como a herança. Extenda a classe que você acha que tem problemas e faça da forma que quiser, entendeu? Ou melhor, usando a estrutura que o java provê, crie suas próprias classes.
Ficar sentado, coçando o saco é fácil, agora, meter a mão na massa, tomar a iniciativa, isso é complicado, não é?
Deus podia me dar uma BMW. Nada cai do céu, se eu não for atrás do que quero, não terei uma BMW.

#11

Discordo nesse ponto.

Eu acho que sobrecarga pode dar uma ilusão de polimorfismo, mas discordo principalmente porque quando você sobrecarrega um método nada garante que a implementação será a mesma.

#12

@drsmachado
Acredito que tenha mais gente que entenda meu ponto de vista.
A linguagem evolui de acordo com a adoção dos programadores e do marketing que é feito em cima dela.

Lembro bem, quando na faculdade, fui em uns 5 eventos de java (todos não paguei um centavo) e a sun e oracle investiam pesado em marketing.
O java é excelente, é minha linguagem preferida, gosto muito de groovy, mas ela é nova, não está consolidada no mercado.
Só que podia ser melhor, quando você gosta muito de alguma coisa, quer que ela melhore.

E sobrecarga de operadores não tem nada a ver com programação estruturada, não fale groselha.

#13

Discordo nesse ponto.

Eu acho que sobrecarga pode dar uma ilusão de polimorfismo, mas discordo principalmente porque quando você sobrecarrega um método nada garante que a implementação será a mesma.[/quote]

int i = 1 + 1;
String a = "Valor: " + (1 + 1);

Sobrecarga de operadores…

#14

[quote=drsmachado] int i = 1 + 1; String a = "Valor: " + (1 + 1);
Sobrecarga de operadores…[/quote]
Não entendi o que você quis dizer.

Onde isso se relaciona com sobrecarga ser uma forma de polimorfismo?

#15

@drsmachado
já que esse é um forum usado pra aprender também

me explique como eu consigo fazer isso funcionar em java

BigDecimal a = new BigDecimal("10.3");
BigDecimal b = new BigDecimal("10.3");
BigDecimal c = a + b;

a linguagem não permite que eu faça isso, não tem como eu tirar a bunda da cadeira e fazer isso
o máximo que eu posso fazer é sugerir uma JSR para incorporarem isso numa versão futura do java
Eu acredito que já exista essa JSR, eu só não consegui localizar.

Esperava que alguém melhor instruído chegasse e dissesse: “olha já tentaram fazer isso na JSR X mas não deu certo por tal motivo” e a partir daí tentar evoluir para uma discussão mais construtiva
E não que chegasse alguém e falasse: “olha você é preguiçoso, não sabe o que ta falando, tira a bunda da cadeira.”, eu sei sim o que estou falando, se fizesse uma votação no GUJ para determinar quem gostaría que o java tivesse operações diretas com BigDecimal, essa votação ia ganhar com louvor.

#16

[quote=digaoneves][quote=drsmachado] int i = 1 + 1; String a = "Valor: " + (1 + 1);
Sobrecarga de operadores…[/quote]
Não entendi o que você quis dizer.

Onde isso se relaciona com sobrecarga ser uma forma de polimorfismo?[/quote]
Veja que o comportamento do operador ‘+’ é diferente em cada caso.
Isso pode dar a interpretação de ‘muitas formas’…
Eu, particularmente, discordo. Enfim.

#17

@drsmachado
Ah, tem mais um ponto.
No mundo real, tem programador ruim ganhando bem, e programador bom ganhando mal.
Quando você aprende a programar, vocÊ aprende a programar, e não gerenciar sua carreira ou fazer marketing pessoal.
Então, não podemos dizer que é culpa do mercado que paga pouco pra programador ruim. O cara pode ser excelente programador, mas vem de uma familia pobre e tem que aceitar o primeiro emprego que oferecem pois tem gente dependendo dele, o cara pode não poder se arriscar.
Então tente não ser injusto com a situação das pessoas, você não sabe como elas vivem e as dificuldades que tiveram ou têm na vida.

#18

Java não possuía qualquer mecanismo de persistência diferente do JDBC. Alguém teve a idéia de criar uma forma de fazer isso, sem precisar que o programador criasse queries. O Hibernate é um exemplo disso e, depois de alguns anos, o JPA foi criado.
Se não está satisfeito, se acha que seria melhor de outra forma, camarada, pare de reclamar aqui e vá procurar os meios adequados.
Se não for aceita a sua idéia, ao menos você tentou. Simples. é apenas isto que eu estou tentando dizer desde que respondi a primeira vez. Manja?

#19

[quote=drsmachado]Veja que o comportamento do operador ‘+’ é diferente em cada caso.
Isso pode dar a interpretação de ‘muitas formas’…
Eu, particularmente, discordo. Enfim.[/quote]

Isso, foi exatamente isso que eu quis dizer.

Eu discordo de que sobrecarga seja uma forma de polimorfismo, justamente porque a implementação pode mudar.

#20

[quote=Rafael Rossignol]@drsmachado
Ah, tem mais um ponto.
No mundo real, tem programador ruim ganhando bem, e programador bom ganhando mal.
Quando você aprende a programar, vocÊ aprende a programar, e não gerenciar sua carreira ou fazer marketing pessoal.
Então, não podemos dizer que é culpa do mercado que paga pouco pra programador ruim. O cara pode ser excelente programador, mas vem de uma familia pobre e tem que aceitar o primeiro emprego que oferecem pois tem gente dependendo dele, o cara pode não poder se arriscar.
Então tente não ser injusto com a situação das pessoas, você não sabe como elas vivem e as dificuldades que tiveram ou têm na vida.[/quote]
Mas aí é que está, mesmo o cara que vem de família humilde, que necessita de qualquer oportunidade, sendo bom programador, logo percebe que pode crescer no mercado (true own history). Se você não conhece seu potencial ou é ruim mesmo, aí não adianta saber, precisa de marketing.
Além do mais, a maior culpa é de quem contrata. Enquanto um cara bom mesmo pede X, um cara ruim pede X/2. Logo, o sujeito pensa “posso contratar esse e economizar uma grana”. Aí começa a nivelar o mercado por baixo…