Sobrecarga de Operadores

Luca wrote:
Como disse o CV, não é coisa que todo mundo iria usar a toda hora. Mas nos poucos momentos em que pode ser útil seria muito vantajoso. Um exemplo clássico são as aplicações que precisam de números complexos. Outro momento em que faz falta é quando a gente usa BigDecimal ou quer fazer operações aritméticas com vetores.

Exato! Isso já fez muito falta (no uso de BigDecimal).
No meu caso, o sistema permite que usuários - super acostumados com excel - definam algumas formulas que o sistema precisa calcular.
Imagine o cara (que não é de TI) escrevendo taxaX.add(valorY). Não é natural.
Nesse caso fui salvo pelo groovy, mas se não fosse permitido usa-lo eu teria problemas.

Fora o uso matematico, acho que como o ViniGodoy disse, o uso é um tanto questionável.

[]´s

Virtual Machine Man Membro desde: 04/07/2007 18:28:58 Mensagens: 824 Offline

O que eu estou achando estranho nessa conversa é achar que sobrecarga de operador só existe para operações aritméticas. Não é. Eu não sei quanto a vocês, mas eu aprendi C++ depois que eu aprendi Java, quase no mesmo período do Ruby on Rails. E eu pude perceber o seguinte: em C++ tem sobrecarga de operador pra tudo!

Por exemplo: o operador() que faz com que um objeto aja como uma função, o operador-> que "derreferencia" um objeto, mesmo que este esteja alocado no stack, e o operador qualquer_coisa(), que transforma um objeto em outro, sendo possível criar um código desse jeito abaixo, sem nenhum problema de compilação:

O C++ é um caso extremo, é uma linguagem que tem a vantagem de permitir você fazer tudo, e que tem a desvantagem de permitir você fazer tudo.
Porém a sobrecarga é útil associado a outros recursos da linguagem. Em C++, poderíamos usar templates em um método cujo único requisito é que tipo de entrada tivesse o operador +; em Ruby, com a tipagem dinâmica, receberiamos qualquer coisa de um método, também cujo requisito fosse o operador +.
Além disso, em C++, a sobrecarga é o único meio de se adicionar recursos depois que a classe já tivesse sido "fechada". Já em Ruby, não existe classe fechada.

Em Java, não tem nada parecido com tipagem tipagem dinânica, nada parecido com templates (tá, tem gente que acha que Generics é Template, eu digo que não, pois Generics é muito restritivo e não passa de "syntactic-sugar"), nada para extender um objeto. E ainda por cima, criou-se uma divisão artificial entre tipos primitivos e objetos, que não existe paralelo nem em C++, nem em Ruby.

Acredito que uma linguagem de programação como Java pode sim ter sobrecarga de operadores, desde que fose adicionado outros recursos como alguma refatoração na especificação do Generics (coisas básicas como permitir T var = new T() dentro uma classe que receba um generic), algum recurso de programação orientada a aspectos e a uniformização entre tipos primitivos e objetos.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

saoj wrote:
Seria muito bom para contornar o sofrível suporte a aritmética com datas do Java....

Na boa verdade aritmética com datas não existe. (Qual seria o resultado de 1/1/2000 + 1/1/2007 ?)
Existe aritmética de intervalos de tempo, e mesmo assim não existe 1 aritmética existem várias.
Por exemplo: 1/1/2007 - 1/1/2000 poderia ser 7 anos , poderia ser 365*7 anos , poderia ser o numero exato de dias transcorridos entre as datas (!) poderia ser o numero de dias uteis entre as duas datas, poderia ser o numero de meses entre as datas, poderia ser o numero de seculos entre as duas datas, etc...

Data é conceito de depende fortemente do conceito de calendário. E calendário é uma subdivisão do tempo de forma que depende de fatores culturais.

Os operadores + e x não estão definidos e o operador - que ainda faz algum sentido, tem N formas de ser intrepretado. E qualquer uma delas resulta em um numero e não em uma data.

Trabalhar com datas é muito mais difícil do que parece. E parece-me que não seria tão boa ideia ter suporte a estas aritméticas usando operadores.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

rodrigo_gomes wrote:

Luca wrote:
Como disse o CV, não é coisa que todo mundo iria usar a toda hora. Mas nos poucos momentos em que pode ser útil seria muito vantajoso. Um exemplo clássico são as aplicações que precisam de números complexos. Outro momento em que faz falta é quando a gente usa BigDecimal ou quer fazer operações aritméticas com vetores.

Exato! Isso já fez muito falta (no uso de BigDecimal).

Estou vendo muitos de vc defenderem este ponto.
Mas lembrem-se do porquê de BigDecimal não ser um tipo primitivo e do porque de vc poder usar MathContext e do porquê da divisão ter um modo de arredondamento. Sendo assim o que seria a / b ?
Os operadores poderiam favorecer os casos triviais ( que o groovy resolve) mas não os casos especiais, e ai , teria que entrar o uso dos métodos comuns. Ora, se vai usar os métodos comuns, por consistência e simplicidade use esses metodos sempre e não complice a vida tendo que inferir o que significa a/b

O mesmo poderia ser pensado para tipos como Money. Parece razoável que a + b seja possivel com dinheiro, mas na realidade não é. Se a e b não tem a mesma unidade, não são somáveis. Mas eu poderia querer , mesmo assim ,somar. Usando o padrão MoneyBag. Como definir qual eu quero usar ? Com métodos é simples :
a.plus(b) e a.add(b) , com operadores teria que inventar dois operadores diferentes. a +_ b e a _+ b ?

Se existir a possibilidade de construir esses operadores, concerteza alguem os vai definir. Mas alguem entende o que eles significam só de olhar ?

A utilidade dos operadores , quaisquer que sejam , é diretamente proporcional à unicidade do seu significado.

a + b para numeros é simples, mas a/ b nem sempre é simples. Para inteiros tem certas regras, paras doubles tem outras, mas ambas são bem definidias ( ou seja, não existem casos desconhecidos)
alguem deu o exemplo do + para substituir append() no StringBuffer/Builder, so que + já é um operador entre CharSequence

StringBuffer a
StringBuffer b

c = a + b , significa c = new StringBuilder().append( String.valueOf(a)).append( String.valueOf(b) );
e não c = a.append(b). A diferença está no new; c tem que ser um objeto tal que c != a e c != b
caso contrario vira uma zona. a.append(b) não pode retornar um buffer diferente, ele retrorna this exactamente
para não forçar a criação de objetos intermediários ( que é o objetivo de usar buffer/builder)

Usar + é prático, mas todo o mundo sabe que não se deve usar. StringBuffer (StringBuilder) é preferivel.
Isso é suficiente para mostrar como o uso de sobrecarga de operadores é danoso e perigoso, mesmo até aquele que o java já tem.

JavaChild Membro desde: 18/07/2006 10:03:59 Mensagens: 124 Offline

sergiotaborda wrote: alguem deu o exemplo do + para substituir append() no StringBuffer/Builder, so que + já é um operador entre CharSequence

Operador entre CharSequence ? onde ?

pelo que eu saiba voce naum pode fazer isso:

sergiotaborda wrote:c = a + b , significa c = new StringBuilder().append( String.valueOf(a)).append( String.valueOf(b) );

Não.. no caso significaria:

onde o operador + sobrecarregado seria:

sem o new.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3196 Offline

AndrewAguiar wrote:

sergiotaborda wrote: alguem deu o exemplo do + para substituir append() no StringBuffer/Builder, so que + já é um operador entre CharSequence

Operador entre CharSequence ? onde ?

Bom, na verdade é entre qq Object. eu restringi a CharSequence para ter mais significado no contexto
dos operadores, mas ok.

pelo que eu saiba voce naum pode fazer isso:
CharSequence b1 = new StringBuilder(); CharSequence b2 = new StringBuilder(); System.out.println( b1 + b2 );

Porquê ? que erro é que dá ?

This message was edited 1 time. Last update was at 06/09/2007 14:05:36

Acho que o maior problema aqui é o seguinte.

Programadores são seres humanos.

E seres humanos pensam de formas diferentes, e tem conceitos diferentes do que é "natural" e do que é "bom senso".
Os implementadores do cout e cin tiveram bom senso ao fazer isso?

Além do mais, não se pode esperar que todos numa equipe tenham experiência e nem bom-senso. Um dos pontos fortes do Java é que, com pouco esfoço, você pode entender o que um programa está fazendo. Os métodos tem nomes explícitos. A própria sun estimulou a clareza do código ao fornecer uma api com pouquíssimas abreviações. Nada de strcat e sim String.concat. A comunidade como um todo seguiu essa filosofia.

Então, me questiono. Até que ponto perder a vantagem da sobrecarga é realmente um benefício? Perder a clareza não pode trazer mais mal do que bem? Vi algumas pessoas falando que outras linguagens são mais rebuscadas e que portanto o java tem "espaço" para isso, mas isso é realmente uma vantagem?

Muita gente pode alegar: "Mas é só ler a documentação e entender que o fulano já se acostuma". Ok, mas ler documentação e entender é um custo chamado "curva de aprendizado". E para interiorizar um conceito, ele terá que ler uma documentação não uma, mas duas, três ou quatro vezes. E alguém terá que manter essa documentação atualizada. Alguém aí já trabalhou num projeto com uma documentação 100% atualizada? Se você já teve problemas para entender um método sem uma boa documentação, imagine um operador sem uma boa documentação!

What is classpath? Membro desde: 30/01/2008 10:05:13 Mensagens: 9 Offline

ViniGodoy wrote:Acho que o maior problema aqui é o seguinte.

Programadores são seres humanos.

E seres humanos pensam de formas diferentes, e tem conceitos diferentes do que é "natural" e do que é "bom senso".
Os implementadores do cout e cin tiveram bom senso ao fazer isso?

int x; cin >> x; cout << "Vinícius tem " << x << " anos";

Além do mais, não se pode esperar que todos numa equipe tenham experiência e nem bom-senso. Um dos pontos fortes do Java é que, com pouco esfoço, você pode entender o que um programa está fazendo. Os métodos tem nomes explícitos. A própria sun estimulou a clareza do código ao fornecer uma api com pouquíssimas abreviações. Nada de strcat e sim String.concat. A comunidade como um todo seguiu essa filosofia.

Então, me questiono. Até que ponto perder a vantagem da sobrecarga é realmente um benefício? Perder a clareza não pode trazer mais mal do que bem? Vi algumas pessoas falando que outras linguagens são mais rebuscadas e que portanto o java tem "espaço" para isso, mas isso é realmente uma vantagem?

Muita gente pode alegar: "Mas é só ler a documentação e entender que o fulano já se acostuma". Ok, mas ler documentação e entender é um custo chamado "curva de aprendizado". E para interiorizar um conceito, ele terá que ler uma documentação não uma, mas duas, três ou quatro vezes. E alguém terá que manter essa documentação atualizada. Alguém aí já trabalhou num projeto com uma documentação 100% atualizada? Se você já teve problemas para entender um método sem uma boa documentação, imagine um operador sem uma boa documentação!

Onde eu assino ?

Smalltalk Membro desde: 06/05/2009 12:34:44 Mensagens: 1 Offline

Concordo com a sobrecarga!!!
Não acho que o código fica mais confuso acho q por default não deveria haver e dar erro de compilação... e somente ter sobrecarga classes onde fosse obvio seu uso, números, string, etc.

PolynomialFunction a = new PolynomialFunction();
PolynomialFunction b = new PolynomialFunction();
PolynomialFunction sum = null;
PolynomialFunction mult = null;

...

// sem sobrecarga
sum = PolynomialFunction.sum(a, b);
mult = PolynomialFunction.mult(a, b);
// com sobrecarga
sum = a + b;
mult = a * b;

...

Notícias, artigos e o maior fórum brasileiro sobre Java