[Reclamação] Double vs BigDecimal

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.

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

Rafael Rossignol:

(que já foi provado por a+b que não é bem um problema, é assim que é e ponto final)

é 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);

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.

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.

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);

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.

@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.

Rafael Rossignol:

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.

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.

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.

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

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.

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.

@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.

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.

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

Sobrecarga de operadores…

drsmachado:

int i = 1 + 1; String a = "Valor: " + (1 + 1);
Sobrecarga de operadores…

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

@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.

digaoneves:

drsmachado:

int i = 1 + 1; String a = "Valor: " + (1 + 1);
Sobrecarga de operadores…

Não entendi o que você quis dizer.

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

@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.

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?

drsmachado:

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

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.

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.

digaoneves:

drsmachado:

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

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.

Mas isso também se aplica a varias outras coisas:

class Calculadora {
	double soma(double valor1, double valor2) {
		return valor1 + valor2;
	}

	double soma(int valor1, int valor2) {
		return valor1 - valor2;
	}
}

Cabe ao programador decidir isso.

O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.

Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …

Ainda sobre essa discussão de “pensar ou não pensar” orientado a objetos que o drsmachado tanto frisa, lembre-se que a linguagem de programação Java não é 100% OO, temos com exemplo a classe String e seus métodos estáticos, e por ai vai, então violar OO em alguns pontos é uma prática bem disseminada entre os desenvolvedores.

Já questão de legibilidade não eh um grande problema quando se domina a API que esta utilizando, porém, o que o proprietário do post quis dizer foi que mesmo em OO podemos utilizar de um mecânismo de adição para determinados tipos de objetos, em matemática existe isso, por exemplo: sejam A e B dois conjuntos do plano cartesiano, e seja “x” e “y” elementos de A e B, respectivamente. Todos sabem desde o colégio que podemos efetuar x + y, e eles não são números (escalares).

abrs…

Mude para C++ , ou C# , ou praticamente qualquer outra linguagem moderna

A linguagem Java (não sei se intencionalmente ou não) acabou ganhando essa característica de ser totalmente “formal”, “quadrada”. Acho que nunca terá sobrescrita de operadores, nem acesso a coleções no estilo array, nem funções anônimas, nada dessas features descoladinhas que vemos por aí.

De fato, não tem nada a ver com orientação a objeto ou não, é questão de estilo.

Sem_Nome:

Mas isso também se aplica a varias outras coisas:

class Calculadora {
	double soma(double valor1, double valor2) {
		return valor1 + valor2;
	}

	double soma(int valor1, int valor2) {
		return valor1 - valor2;
	}
}

Cabe ao programador decidir isso.

O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.

Com seu exemplo você está exemplificando o meu ponto de vista. É por isso que eu não concordo que sobrecarga seja polimorfismo, apesar dependendo da implementação, pode dar essa ilusão.

Quanto a sobrecarga de operadores, existem linguagens que rodam na JVM e o fazem, Scala é um exemplo.
O criador do Scala o criou para provar que é possível uma linguagem ser orientada a objetos e também funcional.

E quem viu aquela declaração do James Strachan (Criador do Groovy), percebe o quanto Scala está impressionando.

Agora quanto ao Java seguir esse caminho, realmente eu não sei, não encontrei nenhuma JSR que indicasse isso.

@Aleksandro
era esse o ponto que queria chegar, aqui o administrador tem o pé atras de fazer lógica de negocios em java, e sei que esse é um dos motivos.

o @Sem_nome disse “O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.”

Eu queria entender que tipos de impedimentos a sobrecarga de operadores poderia causar, visto que os metodos antigos poderiam continuar existindo.
aí que tá o ponto, eu não entendi porque isso ainda não foi implementado no java, sendo que é util, é legal, é fácil (não sei se é fácil de implementar, estou falando da usabilidade)

digaoneves:

Sem_Nome:

Mas isso também se aplica a varias outras coisas:

class Calculadora {
	double soma(double valor1, double valor2) {
		return valor1 + valor2;
	}

	double soma(int valor1, int valor2) {
		return valor1 - valor2;
	}
}

Cabe ao programador decidir isso.

O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.

Com seu exemplo você está exemplificando o meu ponto de vista. É por isso que eu não concordo que sobrecarga seja polimorfismo, apesar dependendo da implementação, pode dar essa ilusão.

Quanto a sobrecarga de operadores, existem linguagens que rodam na JVM e o fazem, Scala é um exemplo.
O criador do Scala o criou para provar que é possível uma linguagem ser orientada a objetos e também funcional.

E quem viu aquela declaração do James Strachan (Criador do Groovy), percebe o quanto Scala está impressionando.

Agora quanto ao Java seguir esse caminho, realmente eu não sei, não encontrei nenhuma JSR que indicasse isso.

Entendo. Achei que você se referia apenas a sobrecarga de operadores.

Não há nada no Java que impossibilite uma forma limitada de operator overloading para BigDecimal.

O único problema é com a divisão, porque o método “divide” com apenas 1 parâmetro é normalmente inútil na prática (já que ele provoca uma exceção quando você tem como resultado uma dízima periódica).

O correto, a meu ver, é ter um tipo “Currency” na linguagem (assim como existe um no C#), que é o principal caso de uso de BigDecimal. O BigDecimal “em si”, devido ao fato de ser muito geral, deveria ser deixado como está.

Esse Currency seria um BigDecimal mas com as operações usando sempre o MathContext.DECIMAL128 (que é o formato IEEE 754R Decimal128 ) . Como o MathContext seria fixado, é possível otimizar as operações nesse caso.

Pense bem - só porque a linguagem é orientada a objetos você precisa trabalhar com dados imutáveis como se fossem objetos também? Acho um pouco radical (xiita) demais. Eu prefiro que a linguagem reflita a linguagem que se usa no domínio do uso. Senão, você faria tudo como objetos, e você teria sempre que escrever:

int x = 3.add (4).mul (5).div (7).chs();

para representar algo tão simples como -(3+4)*5/7.

Aleksandro:

Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …

Não acredito que Java seja a melhor opção para uma aplicação voltada a rotinas numéricas, por exemplo: resolver equações diferenciais usando Java não é computacionalmente inviável.

abrss

@gomesrod
fala pro meu chefe que agora vamos desenvolver o ERP aqui da empresa em C++

@entanglement
concordo com você

@digaoneves
as closures deram tão certo nas linguagens de script que foram para o java

@Vini Fernandes
Bom, 90% dos sistemas que temos por aí pra desenvolver são ERPs, sistemas de informação convencionais, etc…
Qual as primeiras linguagens que vem em mente? java? C#?

Num país como o nosso, onde as leis fiscais e impostos são a m… que são (desculpe o palavreado), cai nesse ponto.
Eu nem isso, pense num sistema de MRP ou num simples sistema de estoque com valorização de estoque, as vezes tem que fazer contas um pouco mais elaboradas, e tem 12 campos de impostos cada vez, se fosse um único campo, até vá la, usar os metodos para fazer os cálculos.
Imagina você calcular base e valor de: ipi, icms, icms-st, pis, pis-st, cofins, cofins-st, mva de cada um, e por aí vai.

Só acho que seria um grande facilitador, talvez uma nova classe como foi sugerido, como tem no C#, pra trabalhar com grana.

Rafael Rossignol:

@digaoneves
as closures deram tão certo nas linguagens de script que foram para o java ;)

Mas não posso negar que é um avanço.

Rafael Rossignol:

@gomesrod
fala pro meu chefe que agora vamos desenvolver o ERP aqui da empresa em C++

Agora, se quiser pensar em uma solução mais palpável: (nunca fiz nada parecido, mas sei que teoricamente é possível)
E se os componentes responsáveis pelos cálculos “chatos” fossem escritos em uma linguagem diferente?
Há pelo menos três maneiras para isso:
uma é usar o recurso de interpretação de linguagens de script
outra é usar uma linguagem suportada pela JVM e que possua os recursos desejados.
e a terceira é criar seu próprio mecanismo de interpretação de expressões e resolução de cálculos, onde você entraria com uma expressão escrita de forma mais natural.

@gomesrod
a segunda solução acho uma solução legal, já havia pensado nisso
Escrever EJBs em groovy ou scala talvez

Vini Fernandes:

Aleksandro:

Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …

Não acredito que Java seja a melhor opção para uma aplicação voltada a rotinas numéricas, por exemplo: resolver equações diferenciais usando Java não é computacionalmente inviável.

abrss

Sim, concordo com você, na verdade quando mencionei o meu case que foi real, na época 2005 …rs…nem faz tanto tempo assim, java no brasil era imaturo ainda e claro , mesmo assim, perdemos tempo criando ambos os códigos em paralelo (java e pl/sql) e testamos ambas as situações até o fim do processo, onde concluímos que naquele momento era mais viável para aplicação e para o negócio a utilização das procedures em pl/sql. mas depois de alguns meses evoluimos o código feito em java e a diferença não era tão assustadora , uma vez que também havia evoluido os frameworks (struts 1.2 e hibernate) enfim …acho sim , que nós devemos nos orientar no que é bom para a empresa e ou aplicação e não ficar se escorando no que eu sei apenas , ou no que eu defendo …enfim é mera opinião …gosto de java , mas se eu souber fazer tal pedaço de código em outra linguagem e que se integre a minha aplicação sem problemas e seja melhor que fazer em java e minha equipe saiba o que eu estou fazendo , não vejo nenhum problema, por isto sempre digo , aprenda mais de uma linguagem e seja feliz …

e para finalizar , certa vez eu li aqui no guj uma frase assim: