pelo que li overloading pode ser sim considerado polimorfismo, mas não polimorfismo verdadeiro…
mais opiniões
http://en.allexperts.com/q/Java-1046/method-overloading-polymorphism.htm
André Fonseca
Pelo visto há uma certa polêmica se sobrecarga d métodos pode ser considerado polimorfismo ou não …
Pelos links q vc passou realmente consideram como polimorfismo … mas eu particularmente fico com a opinião d q realmente não há polimorfismo pois apenas os métodos possuem o mesmo nome. No exemplo o método soma poderia ser somaInt, somaDouble e somaString, como bem disse o colega Lavieri …
oi
não acho polêmica, acho definições diferentes, qual a diferença entre considerar overloading falso polimorfismo ou não considerar polimorfismo?
na minha opinião o importante é vc saber o que é e principalmente quando usar e quais as vantagens vc pode obter 
No fundo acabam sendo apenas questões conceituais … denominações …
boa discussão esse seu tópico … :thumbup:
[quote=André Fonseca]oi
não acho polêmica, acho definições diferentes, qual a diferença entre considerar overloading falso polimorfismo ou não considerar polimorfismo?
na minha opinião o importante é vc saber o que é e principalmente quando usar e quais as vantagens vc pode obter [/quote]
acho que a diferença é pq não é polimorfico so isso… ^^ … são apenas varios métos, com mesmo nome, mas não há nenhum morfismo entre eles… não existe relação entre os 3 métodos, de forma alguma, eles só estão ali escrito com mesmo nome, o que torna tudo mais simples na hora de escrever claro…
Quando vc fala em polimorfico é a capacidade de assumir que algo pode ser em diversas formas… assumir que sobrecarga é polimorfismo seria o mesmo que dizer
[code]public class MinhaClasseMaluco {
void addProduto(Produto p) {}
void addFuncionario(Funcionario f) {}
void addCebola(Cebola c) {}
}[/code]
ou seja, existe um polimorfismo ali ? pq o objeto é capaz de aceitar Cebolas, Funcionarios, Produtos ? a resposta vem instantaneamente a mente, pq é facil de ver, que não existe
não é pq eu dou um refactoring e transformo o código anterior nisso
[code]public class MinhaClasseMaluco {
void add(Produto p) {}
void add(Funcionario f) {}
void add(Cebola c) {}
}[/code]
que ele passa a ter muitas formas, ele continua sendo a mesma coisa, a unica diferença é que o método tem o mesmo nome…
e mais, por exemplo, o principio de assumir q o método aceita muitas formas simplismente some… pq vc sempre saberá pra qual método estará enviando seu objeto, e assim ele não idepende da forma …
…
se existisse um único método add(), que aceitasse e interpretasse a forma, ai sim, estariamos diante de algo POLI Morfico…
porem não há nada de poli, ali, a não ser o fato de existirem 3 métodos
[code]public class MinhaClasseMaluco {
void add(Entidade e) {
//se Cebola faz algo
//se Funcionario faz outra coisa
//se Produto faz mais outra coisa
}
}[/code]
esse método acima, vai aceitar os 3 objetos anterior, quando vc manda pra ele, ele é polimorfico, pq ele aceita as 3 formas, vc quando manda pra ele, não escolhe qual forma mandar, ele vai se virar sozinho pra descobrir, e isso sim é polimorfismo…
ter q escolher um método, e só pq ele tem o mesmo nome, pra mim não caracterisa de forma alguma o polimorfismo
…
[quote=Lavieri]
[code]public class MinhaClasseMaluco {
void addProduto(Produto p) {}
void addFuncionario(Funcionario f) {}
void addCebola(Cebola c) {}
}[/code]
ou seja, existe um polimorfismo ali ? pq o objeto é capaz de aceitar Cebolas, Funcionarios, Produtos ? a resposta vem instantaneamente a mente, pq é facil de ver, que não existe
não é pq eu dou um refactoring e transformo o código anterior nisso
[code]public class MinhaClasseMaluco {
void add(Produto p) {}
void add(Funcionario f) {}
void add(Cebola c) {}
}[/code]
que ele passa a ter muitas formas, ele continua sendo a mesma coisa, a unica diferença é que o método tem o mesmo nome…
…[/quote]
E podem ter implementações diferentes para cada tipo de argumento. Para funcionário você pode implementar de uma forma, para produto de outra e para cebola de outra.
Acho que a maior diferença seja com relação aos nomes e parâmetros serem exatamente iguais, no override. Um é sobrescrita o outro é sobrecarga. Em ambos os casos a implementação pode ser diferente. Acredito que pelo fato de na sobrecarga os parâmetros serem diferentes, eles são considerados métodos diferentes, enquanto que na sobrescrita, tudo é igual, o que muda é apenas a implementação, por isso é polimórfico.
[quote] 1. public class MinhaClasseMaluco {
2.
3. void add(Entidade e) {
4. //se Cebola faz algo
5. //se Funcionario faz outra coisa
6. //se Produto faz mais outra coisa
7. }
8.
9. } [/quote]
É apenas um exemplo claro, mas no caso ao invés d utilizar por exemplo if’s ou sentenças switch’s, algum padrão como strategy por exemplo deixaria o método mais … digamos assim … “polimórfico” ainda?? ou melhor, mais flexível eu acho …
[quote=celso.martins][quote=Lavieri]
[code]public class MinhaClasseMaluco {
void addProduto(Produto p) {}
void addFuncionario(Funcionario f) {}
void addCebola(Cebola c) {}
}[/code]
ou seja, existe um polimorfismo ali ? pq o objeto é capaz de aceitar Cebolas, Funcionarios, Produtos ? a resposta vem instantaneamente a mente, pq é facil de ver, que não existe
não é pq eu dou um refactoring e transformo o código anterior nisso
[code]public class MinhaClasseMaluco {
void add(Produto p) {}
void add(Funcionario f) {}
void add(Cebola c) {}
}[/code]
que ele passa a ter muitas formas, ele continua sendo a mesma coisa, a unica diferença é que o método tem o mesmo nome…
…[/quote]
E podem ter implementações diferentes para cada tipo de argumento. Para funcionário você pode implementar de uma forma, para produto de outra e para cebola de outra.
Acho que a maior diferença seja com relação aos nomes e parâmetros serem exatamente iguais, no override. Um é sobrescrita o outro é sobrecarga. Em ambos os casos a implementação pode ser diferente. Acredito que pelo fato de na sobrecarga os parâmetros serem diferentes, eles são considerados métodos diferentes, enquanto que na sobrescrita, tudo é igual, o que muda é apenas a implementação, por isso é polimórfico.[/quote]
acho q não é so isso… quando vc sobrescreve… vc não avisa a ninguem, vc faz isso, e isso é automatico, ninguem precisa saber… tudo continua igual, vc trocou o seu modo de operar para aquele método. Se alguem tratar vc, como se vc fosse uma classe de um SuperTipo seu (mesmo que esse supertipo seja uma interface) … ele vai continuar trabalhando igual… a diferença é na sua forma de agir…
O mesmo não ocorre com sobrecarga… vc pode ate roubar um fluxo, que anteriormente iria para outro método, mas a outra classe vai sim ser avisa, tanto é verdade que ser por exemplo
//versao 1
public class Produto {
private String s;
public Produto(String s) { this.s = s;}
pulbic boolean equals(Object o) {
return o instanceof Produto && s.equals(((Produto)o).s);
}
}
Veja que eu to usando o equals
[code]public class MinhaClasseDesligada {
public void doStuff() {
Produto um = new Produto(“alhos”);
Produto dois = new Produto(“bugalhos”);
if (um.equals(dois))
System.out.println(“iguais”);
else
System.out.println(“diferentes”);
}
}[/code]
agora digamos q eu mude a minha classe Produto
//versao 2
public class Produto {
private String s;
public Produto(String s) { this.s = s;}
pulbic boolean equals(Object o) {
return o instanceof Produto && s.equals(((Produto)o).s);
}
public Integer equals(Produto o) { //<<== sobrecarga com retorno diferente
return 1;
}
}
é tão verdade que há aviso, que a classe MinhaClasseDesligada para de funcionar… pq um retorno que antes era boolean virou Integer… tudo bem que o fluxo passou a ser outro… mas o método é realmente outro… ele so tem o mesmo nome… mas não precisa nem ser a mesma coisa, nem retornar a mesma coisa… ele simplismente pode ser algo totalmente diferente… que não tem nada a ver… e por isso n tem como conciderar polimorfismo
Hehe,
Pois é, já tiveram essa discussão aqui antes
Agora outra citação
As minhas conclusões
para entender polimorfismo em Java precisa entender a diferença entre dynamic e static binding
se pensarmos em OO overloading NÃO pode ser considerado polimorfismo
Porque deveria haver um consenso para implementar polimorfismo?
A ideia esta clara, o comportamento pode variar enquanto a interface seja a mesma, existem diferentes formas de implementar polimorfismo no nivel da linguagem, e outrar serao inventadas. Esse tipo de detalhe so importa pra quem quer se aprofundar no design de linguagens de programacao, é o seu caso?
sim, esse é o meu caso, sou bastante detalhista as vezes, o conceito de polimorfismo do Java foi meio que aproveitado do C++ onde você tem outros conceitos como funções virtuais, por isso talvez a confusão …
t+