Existe polimorfismo sem herança

Boa pergunta. Acho que sim, usando interfaces.

Não, não existe polimorfismo sem uma hierarquia. Existe herança seja usando “extend” ou “implements”.

Não… polimorfismo o que significa muitas formas é um conceito usado pelo “é um”…

interface Face {
    public void doIt();
 }

 class A implements Face {
    public void doIt() {
      System.out.println("A");
    }    
 }

 class B implements Face {
    public void doIt() {
      System.out.println("B");
    }    
 }

 class Teste {
    public static void main(String args[]) {
      Face f = new A();
      Face f2 = new B();
      f.doIt();   //Saida A
      f2.doIt(); //Saida B
    }    
 }

Como pode ver temos a interface Face a qual poderia tbm ser uma classe o qual as outras subclasse as usassem… a interface Face tem o metodo doIt o qual é implementado/herdado pelas subclasses A e B porem este metodo tem uma “forma” em A e outra em B executando funções distintas nestas classes distintas…
tanto A como B passam no teste “é um” com Face…
bem grossamente isto é um conceito de polimorfismo…
porem lembre-se quem tanto uma classe concreta herdada como uma interface suas subclasses (classes que herdam/implementam elas) passam no teste “é um”… o conceito de herança não significa que tenha que ser com classes usando extends… vc pode usar interfaces como no meu exemplo… aliais é sempre melhor vc usar interfaces do que classes pais (classe que tera outras que vão herdar dela…) procure sempre evitar herança com “extends” prefira interfaces…

Boa pergunta, e se formos para ruby, duck typing pode ser considerado polimorfismo sem herança?

interfaces usam o conceito de herança… a diferença é que em uma interface todos os metodos nela que serão herdados pelas classes filhas devem ser obrigatoriamente implementados… ja com classes não abstratas com metodos não abstratos qdo estes metodos são herdados vc não precisa implementalos na classe que os herdou…

Hmm… então implementar uma interface também é considerado herança.

Ótima pergunta, o wikipedia responde:

Polimorfismo tem um contexto mais amplo. Embora tenha sido convencionado pela Sun não usar a terminologia assim para a linguagem Java, sobrecarga de métodos pode ser considerada polimorfismo:

public class X() {
    public void sayIt(int x) {
          System.out.println("X is an integer of value: " + x);
    }

    public void sayIt(double x) {
          System.out.printf("X is a double of value: %.02d", x);
          System.out.println();
    }
}

X x = new X();
x.sayIt(10); //X is an integer of value: 10
x.sayIt(12.5); //X is a double of value: 12.50

No C++, também existe polimorfismo em templates. E não envolve herança. Você pode fazer especialização da template para um determinado tipo. Um exemplo disso é que, no C++, o std::vector<boolean> tem uma implementação especial, usar 1 byte para representar 8 booleans. Note que não estamos falando de um filho de vector, mas do mesmo objeto numa determinada condição de uso.

Diferente dos Generics, no C++, os argumentos de template também tem comportamento polimórfico, pois fazem Duck Typing. Duck Typing implementa o conceito de "Se fala como um pato, e anda como um pato, então é um pato". Demonstrando o conceito, veja o seguinte exemplo:

template<typename T>
T max(T one, T two) 
{
    return one < two ? two : one;
}

One or two podem ser qualquer objeto, ou tipo primitivo, desde que esse suporte o uso do operador <. Se os dois podem ser comparados com o sinal de menor, então essa função deve se comportar como tal. Esse também é um exemplo de polimorfismo sem herança, porque a resolução do tipo é dinâmica e depende apenas dos objetos terem ou não aquela "assinatura". No caso do C++ é feita em tempo de compilação. Linguagens de script, como Groovy e Ruby, fazem em tempo de execução.

Interfaces tem muito menos acoplamento do que a herança.

Elas não dizem que X é um Y. Mas sim que X se comporta como um Y ou, em outras palavras, que X respeita o contrato de Y. Com interfaces, podemos variar a implementação livremente, o que não ocorre com a herança. Conceitualmente, também temos uma diferença. Bom, já houve uma longa discussão sobre isso nesse tópico:
http://www.guj.com.br/posts/list/51866.java#273117

sim são bem menos acoplados de herança porem utilizam o conceito “é um”… interface usa o conceito de herança… se vc olhar bem vai ver que a grosso modo uma interface nada mais é do que uma classe abstrata com todos os metodos declarados abstratos… a questão não são palavras reservadas como: extends e implements e sim o conceito do “é um”…

Danilo_neco:

Existe polimorfismo sem herança.
:?:

Sim. com certeza. Repare que o polimorfismo que necessita de herança é apenas um tipo: o polimorfismo dinâmico.
O polimorfismo estático não depende de herança. Herança é uma forma de criar um escopo léxico suplementar, mas sem ele
ainda temos outros escopos em que o polimorfismo de aplica.

Mais detalhe aqui

Sergio estava olhando seu Wiki…

pq colocou Sobre-escrita como estatico?
sobre escrita é usado com herança… é impossivel vc fazer uma sobscrita na mesma classe…

luistiagos:

Sergio estava olhando seu Wiki…

pq colocou Sobre-escrita como estatico?
sobre escrita é usado com herança… é impossivel vc fazer uma sobscrita na mesma classe…

“sobescrita” não existe. É sobre-escrita (escrever por cima) Portanto sim, é impossivel fazer sobescrita na mesma classe
Agora a sério : sobre-escrita é estático porque vc pode encontrar o resultado real apenas lendo o código. Uma ferramenta que analize o codigo pode saber onde existe sobre-escrita; por isso é estático ( não precisa do runtime).

Polimorfismo não é relacionado a herança em geral. Apenas algumas coisas existem que são relacionadas a herança.
Mas herança é um conceito especial que aumenta os escopos disponiveis. Em outras linguagens sem herança (javacript por exemplo) o mesmo escopo pode ser definido e sobre-escrita poderia ser definida da mesma forma. Polimorfismo se relaciona a escopos. Herança é apenas uma forma de criar um deles.

bem mas vc esta falando de Runtime ou não e não de conceito… o fato de uma sobre - escrita poder ser vista em tempo de compilação não torna tal não sujeita a herança/implementação pois para se usar uma sobscrita vc obrigatoriamente tenque sobscrever o metodo herdado/implementado isto é aplicado ao conceito de herança… isto idepende de runtime… e var-args nada passa de um mode de vc passar um array de um determinado tipo com tamanho variavel… não entendo pq incluiu var-args nesta lista tbm…

Isso é porque vc confunde polimorfismo com herança e não entendeu a diferença entre polimorfismo estático e dinâmico.
Quando vc entender vc vai entender também porque inclui var args. Mas só para não dizerem que sou mau , pense que var args é uma forma especial de sobrecarga.

Ah! e é “sobre-escrita” ( ou sobre escrita) e não “sobescrita”

No seu “se você pensar bem”, você falou da implementação, não do conceito. Em linguagens com duck typing, por exemplo, o conceito de interfaces existe, mas não é necessário qualquer tipo de implementação ou declaração de uma interface formal. Basta a documentação. É o caso do C++ em metaprogramação, por exemplo.

Veja o exemplo que eu passei anteriormente, da função max.
Existe uma interface implícita para o tipo T, que seria algo assim:

interface de T { /** Retorna true se este T é menor que o outro. */ operator < (T outro); }

Mas não há uma classe abstrata ou interface formal definida na linguagem. Tudo será verificado na hora da compilação. No caso do Ruby, na hora da execução.

Agora, herança envolve um acoplamento muito mais forte. Como o Sergio falou, envolve a ampliação do escopo, compartilhamento de dados e de código. E as linguagens terão mecanismos formais para dizer que essa relação ocorreu.

Um usuário pode implementar uma interface, e com isso ele não está dizendo que a sua classe “é outra coisa”. Ele só diz que sua classe “está de acordo com determinado contrato”. É o que acontece quando vc implementa uma interface para se adequar com um framework, por exemplo. Em resumo, o tipo de dado original, não muda. Ele só se torna compatível com determinado método, que espera certas coisas serem cumpridas.

Por outro lado, um usuário não pode fazer herança, sem dizer que a classe dele mudou de tipo. A partir do momento que a herança ocorre ele tem uma nova entidade, que não é mais a mesma de antes da herança. É uma nova classe, mesmo.

É claro que a implementação disso tudo é muito parecida. Métodos como instanceof serão compatíveis com ambos. É conveniente e interessante.

Aliás, vários dos conceitos de OO podem ter implementação idêntica (por exemplo, muitos casos de Associação e Composição). O importante é entender como a relação entre as classes se dá, e não exatamente como elas estão representadas no código de uma determinada linguagem.

Eu não confundo polimorfismo com herança… acho que vc não leu meus outros posts ou se leu não entendeu bulhufas do que eu disse… em parte alguma disse que polimorfismo == herança são coisas destintas… eu posso ter polimorfismo atravez da herança… e posso telo atravez do overload…
templates tbm no C++ (havia me esquecido dos templates) porem var-args realmente não entendi onde vc quer encaixar… pode ser usado em overload sim como qualquer outro tipo… porem isto não o torna nada de especial…

Vini então pelo que vc esta dizendo se eu fizer isto:

abstract class A {
   public abstract void doIt();
}

class B extends A {
  public void doIt() {

  }
}

então se eu disser que B é um A estarei mentindo?

luistiagos:

Isso é porque vc confunde polimorfismo com herança e não entendeu a diferença entre polimorfismo estático e dinâmico.
Quando vc entender vc vai entender também porque inclui var args. Mas só para não dizerem que sou mau , pense que var args é uma forma especial de sobrecarga.

Ah! e é “sobre-escrita” ( ou sobre escrita) e não “sobescrita”

Eu não confundo polimorfismo com herança… acho que vc não leu meus outros posts ou se leu não entendeu bulhufas do que eu disse… em parte alguma disse que polimorfismo == herança são coisas destintas… eu posso ter polimorfismo atravez da herança… e posso telo atravez do overload…
templates tbm no C++ (havia me esquecido dos templates) porem var-args realmente não entendi onde vc quer encaixar… um var arg não passa de um array… isto:

public void foo(int ...x) {

}

é exatamente igual a isto:

public void foo(int []x) {

}

a unica coisa que muda é a chamada do metodo sem var-args vc usa: foo(new int[]{1,2,3}) com var-args:
foo(1,2,3) porem um é igual ao outro… var-args é apenas um recurso da linguagem feito para simplificar a chamada do metodo não precisando criar um array para passar os argumentos porem isto é feito de qualquer modo mas implicitamente… dizer que var-args é uma especie de sobrecarga não é verdade pois:
foo(new int[]{1,2}) e foo(new int[]{1,2,3}) e foo(new int[]{1,2,3,4}) não são overloads e sim apenas um metodo que recebe um array de inteiros…

Vini então pelo que vc esta dizendo se eu fizer isto:

abstract class A {
   public abstract void doIt();
}

class B extends A {
  public void doIt() {

  }
}

então se eu disser que B é um A estarei mentindo?

a diferença é que no var-args vc nao informa quantos paramentos devem ser passados no metodos, vc pode passar de 1 à …

e a respeito de herança e polimorfismo… pense assim, vc herda a herança do seu pai por seu filho. Ja o polimorfismo significa muitas formas… por exemplo todo animal corre ne? mais o gato de uma forma, o cachorro de outra, a galinha de outra entao ai vc tem polimorfismo. todo mundo na mesma cadeia… porem de forma diferente… em trazendo para “familia” sua irma é uma herança do seu pai tb, como vc… mais ela usa calcinha e vc usa cueca, porem ambos usa roupa intima!

flw! hehe!

eu tbm posso ter um array de 1 a … e passa-lo para o metodo veja meu exemplo acima…

para vc ver como eu não sou mentiroso tente compilar isto e veja o que vai dar:

class X {

   public void fazAlgo(int ...arr) {

   }

    public void fazAlgo(int []arr) {

   }

}

se var-args é um tipo especial de sobrecarga isto vai compilar e rodar perfeitamente…

e sobre heraça e polimorfismo ngn aqui disse em momento algum que herança == poliformfismo…
a questão era se existe polimorfismo sem herança… a unica maneira plausivel para isto em java é a sobrecarga… de fato em minha primeira resposta a este post esqueci da sobrecarga que usa o conceito de polimorfismo…

E ai chará,também me chamo danilo e ja tinha posto um topico a respeito deste assunto.

http://www.guj.com.br/posts/list/93258.java#499498

• falando serio,olha o link q mandei,há um certa divergencia de pensamentos e conceitos,sendo que segundo alguns os proprios autores da serie “Use a cabeça” cometem equivoco ao falarem de polimorfismo e herança

luistiagos:

a diferença é que no var-args vc nao informa quantos paramentos devem ser passados no metodos, vc pode passar de 1 à …

eu tbm posso ter um array de 1 a … e passa-lo para o metodo veja meu exemplo acima…

para vc ver como eu não sou mentiroso tente compilar isto e veja o que vai dar:

class X {

   public void fazAlgo(int ...arr) {

   }

    public void fazAlgo(int []arr) {

   }

}

se var-args é um tipo especial de sobrecarga isto vai compilar e rodar perfeitamente…

e sobre heraça e polimorfismo ngn aqui disse em momento algum que herança == poliformfismo…
a questão era se existe polimorfismo sem herança… a unica maneira plausivel para isto em java é a sobrecarga… de fato em minha primeira resposta a este post esqueci da sobrecarga que usa o conceito de polimorfismo…

eu sei apenas abordei um ponto amplo entre os dois para ficar claro… polimorfismo e herança no inicio sao confusos para quem vi de primeiro… e a questao do array tinha esquecido hehe!
Não lembro perfeitamente pq a sun criou var-args a kathy ate explica em um trecho do seu livro… mais nao lembro!

Vini então pelo que vc esta dizendo se eu fizer isto: abstract class A { public abstract void doIt(); }

class B extends A {
public void doIt() {

}
}

então se eu disser que B é um A estarei mentindo?

No caso do extends você não estará mentindo. Mesmo que por enquanto a classe A seja funcionalmente igual a uma interface, não é isso que a relação diz. Diz que B é um A. Portanto, eles compartilham o mesmo escopo, definições e conceito. Num sistema, também significa que vc está autorizado a incluir propriedades e métodos em A futuramente, e B os terá.

Agora, se vc fizer isso:

interface A {
   void doIt();
}

class B implements A
{
   void doIt() { System.out.println("Do it!"); }
}

Você não está falando que B é um A. Mas que B implementa o contrato definido por A. Esta é uma relação apenas comportamental, não envolve tipos.

É claro que outras coisas tornam essa definição confusa, como poder usar instanceof nos dois casos. Mesmo muitos livros tratam o assunto indistintamente. Mas estavamos comentando a respeito do conceito, não da implementação. Como eu cite, no caso do groovy, não haveria aquela interface. Você só teria em alguma momento:

def someMethod(objectWhoCanDoIt) {
   objectWhoCanDoIt.doIt()
}

/** Do itable é um objeto que pode fazer doIt(). 
   O doIt() é uma ação personalizada, tal qual o run() dos Runnables Java.
*/

O que não deixa de ser uma interface, um contrato comportamental. Mas implementada de forma diferente, numa linguagem diferente.

bem então neste exemplo:

interface A {
  final static int x = 4;
}

a classe que implementar esta interface tera herdado a constante x…
dai neste ponto o argumento:
Mas que B implementa o contrato definido por A…
neste ponto B não ira implementar nenhum contrato definido por A ele ira herdar a constante de A…
e se for ver em C++ por exemplo… não existem interfaces e permite-se herança multipla… isto ao meu ver e uma falha na OO… porem isto ja é coisa para outra Thread… porem posso simular herança multipla do C++ com interfaces… por isto creio que no fundo mas bem no fundo por baixo dos panos em java interface na verdade emprega os conceitos de herança…

e a mesma questão que os var-args… nos var-args vc ve a coisa assim:

public void doIt(int... x) {

}

porem a vm enxerga isto:

public void doIt(int []x) {

}

o mesmo acontesse com as interfaces…
vc as ve assim:

interface face {
   public void doIt();
}

class A implements face {
     public void doIt(){}

}

porem a vm enxerga assim:

abstract class face {
   public abstract void doIt();
}

class A extends face {
   public void doIt(){}
}

porem é claro vc dificilmente vai ver em um livro detalhes da vm, do compilador e coisas assim “debaixo dos panos…” por questão de didatica…

luistiagos:

public void foo(int ...x) {

}

é exatamente igual a isto:

public void foo(int []x) {

}

a unica coisa que muda é a chamada do metodo sem var-args vc usa: foo(new int[]{1,2,3}) com var-args:
foo(1,2,3) porem um é igual ao outro...

"a única coisa que muda" é a forma da chamada. Dai ser um tipo de polimorfismo ( várias formas de chamada)

var-args é apenas um recurso da linguagem feito para simplificar a chamada do metodo não precisando criar um array para passar os argumentos porem isto é feito de qualquer modo mas implicitamente... dizer que var-args é uma especie de sobrecarga não é verdade pois: foo(new int[]{1,2}) e foo(new int[]{1,2,3}) e foo(new int[]{1,2,3,4}) não são overloads e sim apenas um metodo que recebe um array de inteiros...

1) "Recurso de Linguagem" é um termo sem significado aqui. Se formos por ai tudo são recursos da linguagem.
2) Embora podendo ser açucar sintático implica em uma forma extra de fazer uma chamada ao método o que sigifica que ha um polimorfismo. (Afinal vc concordo com generics serem um tipo de polimorfismo e na realidade tb não passam de truque de compilação)
3) É claro que podemos entender var args como um a forma de sobrecarga porque é equivalente a escrever isto :

public void metodo ( int a){
    metodo ( new int[]{a});
}

public void metodo ( int a, int b){
    metodo ( new int[]{a,b});
}


public void metodo ( int a, int b , int c){
    metodo ( new int[]{a,b,c});
}

public void metodo ( int[] params){

}

A diferença é que vc só escreve um método e o compilador "escreve os outros" ( na realidade ele altera o codigo para não ter que declarar os métodos, mas tudo bem). Para todos os efeitos o codigo se comporta como se todos os métodos existissem lá. Isso permite chamar o mesmo métodos de formas diferentes :

metodo (1,2 );
metodo (1,2,3 );
metodo ( new int[]{1,2,3} );

O que significa que int ... params é diferente de int[] params "por fora" mas são de alguma forma compatíveis e portanto são formas diferentes da mesma coisa. Ou seja, ( int ... params) representa várias assinaturas de métodos. Várias formas de chamar o mesmo método.

só pra constar, em portugues do brasil, o termo é “sobrescrever” / “sobrescrita”

http://dic.busca.uol.com.br/result.html?q=sobrescrever&group=0&t=10

exatamente ele altera as chamadas para não precisar sobrescrever os metodos ou seja ele faz algo para não precisar usar sobscrita que é algo que usa polimorfismo… e outra em uma sobscrita classica eu teria isto:

public void doIt(int a) {
    //aqui tenho um inteiro
}

public void doIt(int a, int b) {
   //aqui eu tenho 2 inteiros
}

public void doIt(int ...a)  {
  aqui eu tenho um ARRAY de inteiros
}

portanto em uma sobrecarga classica eu poderia usar o primeiro metodo com apenas um tipo primitivo inteiro…
o segundo 2… e o terceiro um objeto array com n inteiros… o conceito de polimorfismo é varias formas e não varias chamadas diferentes… se eu fizer isto:

class A {
public void doIt(int a, int b) {
    System.out.println("sem var-args");
}

public void doIt(int ...a) {
   System.out.println("com var-args");
}

public static void main(String ...args) {
  A a = new A();
  a.doIt(1,2); 
}
}

compila que vc vai ver a saida…
onde a polimorfismo ai? a na sobrecarga entre o var-args e o que passa 2 primitivos… um metodo tem um comportamento, uma forma e o outro outra totalmente diferente…

var-args somente é polimorfico na chamada… assim como meu array de inteiro é polimorfico na chamada… pois posso criar varios arrays passando n elementos diferentes… isto são formas diferentes…

porem o conceito de polimorfismo não extende somente a chamada… e sim o comportamento do metodo…

Sergio Lopes:

só pra constar, em portugues do brasil, o termo é “sobrescrever” / “sobrescrita”

http://dic.busca.uol.com.br/result.html?q=sobrescrever&group=0&t=10

É bom saber. Da ultima vez que procurei não registravam o termo. Nem nos dics do brasil nem de pt.
Agora aparece em ambos.

luistiagos:

A diferença é que vc só escreve um método e o compilador “escreve os outros” ( na realidade ele altera o codigo para não ter que declarar os métodos, mas tudo bem). Para todos os efeitos o codigo se comporta como se todos os métodos existissem lá. Isso permite chamar o mesmo métodos de formas diferentes :

exatamente ele altera as chamadas para não precisar sobrescrever os metodos ou seja ele faz algo para não precisar usar sobscrita que é algo que usa polimorfismo… e outra em uma sobscrita classica eu teria isto:

Cara, assim a discussão não é séria. Vc está misturando sobrescrever com sobescrever (que não existe) com sobrecarga…

Bom, isso é o que vc acha…
Se vc quiser pensar que polimorfismo apenas no que se refere a herança e pensar que tudo o resto ( sobrecarga, sombreamento, var-args, auto-boxing, generic-types, etc…) são funcionalidades da linguagem vá em frente. O problema não é meu. É todo seu.

Agora se vc quiser parar dois minutos e pensar o que significa escopo, “poli-morfismo” e herança vai chegar à conclusão que sim se pode entender “funcionalidades da linguagem” como polimorfismo. A escolha é sua.

Em seu exemplo:

public void metodo ( int a){   
    metodo ( new int[]{a});   
}   
  
public void metodo ( int a, int b){   
    metodo ( new int[]{a,b});   
}   
  
  
public void metodo ( int a, int b , int c){   
    metodo ( new int[]{a,b,c});   
}   
  
public void metodo ( int[] params){   
  
}

vc pode muito bem observar que o unico metodo que tem um comportamento é o que recebe []params o resto não faz nada apenas redireciona para este metodo… ou seja chamando qualquer um deles vc estara chamando o mesmo metodo… e isto não é polimorfismo por sobrescrita… seria se cada um desses metodos tivessem uma função/comportamento distinto…
aliais isto é um exemplo de pog pois todos estes metodos podem ser substituido por um so apenas passando um array na chamada dele…

Pelo que eu sei e aprendi de Orientação a Objeto, polimorfismo só existe com Herança.

Os casos sem herança são os de vc sobrepor um método.

luistiagos:

vc pode muito bem observar que o unico metodo que tem um comportamento é o que recebe []params o resto não faz nada apenas redireciona para este metodo… ou seja chamando qualquer um deles vc estara chamando o mesmo metodo… e isto não é polimorfismo por sobrescrita… seria se cada um desses metodos tivessem uma função/comportamento distinto…
aliais isto é um exemplo de pog pois todos estes metodos podem ser substituido por um so apenas passando um array na chamada dele…

É polimorfismo por sobrescrita! A implementação dos métodos é irrelevante! Até porque a orientação a objetos tem como um de seus objetos ocultar a implementação para o mundo de fora.

E isso não é POG! POG é deixar que rotinas de conversão de tipos, praticamente iguais, fiquem espalhados por todo o sistema, sempre antes de chamar o método do objeto.

acho que vc não leu meu post…
eu não disse que polimorfismo apenas se refere a herança… eu disse que ele não se refere a var-args…

correto… porem este é outro conceito da OO o encapsulamento… estamos aqui falando sobre polimorfismo e var-args…

public void foo() {
   //faz algo
}

public void foo(int x) {
   foo();
}

isto ai em cima é pog… pois o metodo que recebe o x como argumento não faz porra nenhuma alem de chamar
o outro metodo foo() ou seja isto foo(4) é substituido por isto: foo()

agora isto:

public void foo() {
   //faz algo
}

public void foo(int x) {
  //faz outra coisa que não faz em foo 
  foo();
}

não é pog pois foo(x) faz outra coisa e depois chama foo

luistiagos:

Em seu exemplo:

public void metodo ( int a){   
    metodo ( new int[]{a});   
}   
  
public void metodo ( int a, int b){   
    metodo ( new int[]{a,b});   
}   
  
  
public void metodo ( int a, int b , int c){   
    metodo ( new int[]{a,b,c});   
}   
  
public void metodo ( int[] params){   
  
}

vc pode muito bem observar que o unico metodo que tem um comportamento é o que recebe []params o resto não faz nada apenas redireciona para este metodo… ou seja chamando qualquer um deles vc estara chamando o mesmo metodo… e isto não é polimorfismo por sobrescrita…

Pois não é. Nem deveria ser. var agrs é um tipo especial de polimorfismo por sobrecarga

aliais isto é um exemplo de pog pois todos estes metodos podem ser substituido por um so apenas passando um array na chamada dele…

Não , não podem. Por isso que precisamos de var-args

Isto :

metodo ( new int[]{1});  
metodo ( new int[]{1,2});  
metodo ( new int[]{1,2,3});

Não é polimorfismo. É o uso normal do método com arrays literais.

Polimorfismo

Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação (assinatura) mas comportamentos distintos, especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da superclasse. A decisão sobre qual o método que deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de execução, através do mecanismo de ligação tardia.

No caso de polimorfismo, é necessário que os métodos tenham exatamente a mesma identificação, sendo utilizado o mecanismo de redefinição de métodos. Esse mecanismo de redefinição não deve ser confundido com o mecanismo de sobrecarga de métodos.

O uso de polimorfismo em Java é ilustrado através de um exemplo. Através desse exemplo introduzem-se os conceitos relacionados de upcasting e a motivação para a definição de métodos abstratos.

É importante observar que, quando polimorfismo está sendo utilizado, o comportamento que será adotado por um método só será definido durante a execução. Embora em geral esse seja um mecanismo que facilite o desenvolvimento e a compreensão do código orientado a objetos, há algumas situações onde o resultado da execução pode ser não-intuitivo, como ilustra esse exemplo que usa polimorfismo em construtores.

Fonte: http://www.dca.fee.unicamp.br/cursos/PooJava/polimorf/index.html

Volto a repetir não existe polimorfismo sem herança.

Exemplo de polimorfismo:

abstract class Polimorfismo {
	public void imprime(){
		System.out.println("Teste");
	}
}

class PolimorfismoA extends Polimorfismo{
	public void imprime() {
		System.out.println("PolimorfismoA");
	}
}
class PolimorfismoB extends Polimorfismo{
	public void imprime() {
		System.out.println("PolimorfismoB");
	}
}

public class Main {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Polimorfismo exemplo = new PolimorfismoA();
		exemplo.imprime();
		exemplo = new PolimorfismoB();
		exemplo.imprime();
	}

}

não vou repetir se quiser pensar que var-args é um tipo de sobrecarga pense… pq na verdade sobrecarga != var-args

luistiagos:

Bom, isso é o que vc acha…
Se vc quiser pensar que polimorfismo apenas no que se refere a herança e pensar que tudo o resto ( sobrecarga, sombreamento, var-args, auto-boxing, generic-types, etc…) são funcionalidades da linguagem vá em frente. O problema não é meu. É todo seu.

acho que vc não leu meu post…
eu não disse que polimorfismo apenas se refere a herança… eu disse que ele não se refere a var-args…

Ok, então eu reformulo:

Se vc quiser pensar que polimorfismo apenas no que se refere a herança, sobrecarga, sombreamento, auto-boxing, generic-types, etc… e pensar que var-args são funcionalidades da linguagem vá em frente. O problema não é meu. É todo seu.

Mas já agora porque auto-boxing pode ser polimorfismo e não uma " funcionalidade da linguagem" ?
A mesma pergunta é válida para sobrecarga , sombreamento , generic-types, etc…
O que var args tem que estes não têm , ou vice-versa ? (perguntas retóricas)

king_of_gods:

Volto a repetir não existe polimorfismo sem herança.

Tudo bem. Então sombreamento, sobecarga, tipos genericos , auto-boxing são tudo tipos de quê ? “funcionalidades da linguagem” ?
Ok. Mas nesse caso herança tb é apenas uma “funcionalidade da linguagem”. Assim não vamos a lado nenhum…

sergiotaborda:

king_of_gods:

Volto a repetir não existe polimorfismo sem herança.

Tudo bem. Então sombreamento, sobecarga, tipos genericos , auto-boxing são tudo tipos de quê ? “funcionalidades da linguagem” ?
Ok. Mas nesse caso herança tb é apenas uma “funcionalidade da linguagem”. Assim não vamos a lado nenhum…

O que vcs estão batendo cabeça é:

POLIMORFISMO - é uma coisa, SOBRECARGA é outra coisa, SOMBREAMENTO é outra coisa ainda. Todos são tipos de construção de métodos na Orientação a Objeto.

Herança não é funcionalidade da linguagem, herança é uma caracteristica que qualquer linguagem orientada a objeto tem que permitir.

Orientação a Objeto não é dá linguagem JAVA , é um conceito q o JAVA utiliza. Lembre-se disso.

luistiagos:

bem então neste exemplo:

interface A {
  final static int x = 4;
}

a classe que implementar esta interface tera herdado a constante x…

dai neste ponto o argumento:
Mas que B implementa o contrato definido por A…
neste ponto B não ira implementar nenhum contrato definido por A ele ira herdar a constante de A…

Não é a toa que isso é considerado um anti-pattern. Aliás, um anti-pattern tão feio que é citado em especial no Effective Java.
E, novamente, você está pegando aspectos de uma implementação de uma linguagem, para tentar justificar um conceito. A linguagem Java permite esse tipo de aberração, que nada tem a ver com o conceito de interface.

A interface nada mais é do que um contrato entre duas classes. Nada mais. Esse é o conceito. E é exatamente por ser somente isso que elas são tão úteis.

Esse pode ser implementado de várias formas nas linguagens:

1. No C++: Classes abstratas, só com métodos virtuais puros e através de extensão pública ou implicitamente em templates;
2. No Java: Existe uma construção nativa para dar suporte ao conceito, chamada interface;
3. No Groovy e Ruby: implicitamente em runtime, através de duck typing.

O C++ não tem um mecanismo nativo para a implementação do conceito de interfaces. Mas existem interfaces sim, pois há formas de utilizar esse conceito:

1. Criar classes abstratas, sem propriedades, com um construtor vazio e só com métodos virtuais puros. Como a linguagem não dá suporte nativo, não há avisos para o programador caso ele venha a ferir essas regras, mas isso não significa que isso deixou de ser um erro de projeto. Herança múltipla nesse tipo de classe não está sujeita aos problemas do Diamond of Death e, do ponto de vista do projeto, passam a representar uma relação de contrato e não de tipos. Efetivamente, ao usar dessa forma, você deixou de fazer herança para usar interfaces;
2. Usar templates e interfaces implícitas.

O que eu já ressaltei algumas vezes, e parece ser o que você está confundindo, é que o conceito é uma coisa, enquanto o mecanismo que implementa esse conceito é outra totalmente diferente. No C++, o mecanismo que se usa para criar uma interface e uma classe base é exatamente o mesmo. Porém, você só terá a interface caso siga certas regras, que a tornam útil.

king_of_gods:

O que vcs estão batendo cabeça é:

POLIMORFISMO - é uma coisa, SOBRECARGA é outra coisa, SOMBREAMENTO é outra coisa ainda. Todos são tipos de construção de métodos na Orientação a Objeto.

Herança não é funcionalidade da linguagem, herança é uma caracteristica que qualquer linguagem orientada a objeto tem que permitir.

Orientação a Objeto não é dá linguagem JAVA , é um conceito q o JAVA utiliza. Lembre-se disso.

Não existe nenhuma definição formal do que é necessário para uma linguagem ser orientada a objeto. Não há a obrigatoriedade de herança para uma linguagem ser OO. Javascript é um exemplo de linguagem que não possui herança, não possui definição de classe, mas é orientada a objetos.

Com relação a poliformismo, já pensou que sobrecarga é um tipo de polimorfismo?

king_of_gods:

sergiotaborda:

king_of_gods:

Volto a repetir não existe polimorfismo sem herança.

Tudo bem. Então sombreamento, sobecarga, tipos genericos , auto-boxing são tudo tipos de quê ? “funcionalidades da linguagem” ?
Ok. Mas nesse caso herança tb é apenas uma “funcionalidade da linguagem”. Assim não vamos a lado nenhum…

O que vcs estão batendo cabeça é:

POLIMORFISMO - é uma coisa, SOBRECARGA é outra coisa, SOMBREAMENTO é outra coisa ainda. Todos são tipos de construção de métodos na Orientação a Objeto.

Ora aí e´que está.
Sobrecarga e Sombreamento são ambos tipos de Polimorfismo.
(sombreamento não é uma forma de construção de métodos , logo por ai a sua afirmação é falsa.)

Engraçado, porque Polimorfismo tb não é uma funcionalidade da linguagem.

Polimorfismo também. Lembre-se disso…

Na real :

1. Polimorifsmo é um conceito não associado a herança e sim a escopo.
   1.1.) Herança tb é um conceito associado a escopo. Daqui se entende que Polimorfismo => Escopo <= Herança. Ou seja,
   Se tem herança, então deve existir algum polimorfismo associado.
   1.1.1) O polimorfismo associado a herança é a Variável Polimorfica.

2. Existem vários escopos em Java
   2.1) portanto, algum polimorfismo deve estar associado a eles.
   2.1.1) Está, é o sombreamento.

Algumas linguagens não implementam sombreamento. Ok. neste caso o polimorfismo não está implementado. Mas isso não significa que ele não existe.

Veja de outra forma: duck typing comum em linguagens de script é uma forma de polimorfismo. é a “variável super-polimorfica” por assim dizer. Java não tem isso, mas isso não significa que não é uma forma de polimorfismo.

“Superficialmente, polimorfismo é a habilidade de duas classes diferentes de terem cada uma delas uma operação que tenha a mesma assinatura, tendo o mesmo tempo duas formas muito diferentes de código de método para a operação.”

Exemplo de polimorfismo SEM HERANÇA:

public interface Falante {
    public void falar();
}

public class Cachorro implements Falante {
    public void falar() {
        System.out.println("au au");
    }
}

public class Gato implements Falante {
    public void falar() {
        System.out.println("miau");
    }
}

public class Programa {
    private static Falante getFalante() {
        return (new java.util.Date().getTime() / 1000 % 2 == 0) ? new Gato() : new Cachorro();
    }

    public static void main(String[] args) {
        Falante f = getFalante();
        f.falar(); // Se for um gato, vai falar "miau". Se for um cachorro, fala "au au".
    }
}

O conceito de polimorfismo está aí. A implementação variou de acordo com o tipo real da variável. E não há herança.

Polimorfsimo em geral:

Paper de 1985: http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf

Resumindo: existem tipos polimórficos e funções polimórficas. Sobrecarga caracteriza polimorfismo e pode ser encontrado mesmo em linguagens extremamente monomórficas.

A propósito: polimorfismo é um conceito usado em Orientação a Objetos, não da Orientação a Objetos. E OO não precisa de classes, logo não de herança como estamos discutindo aqui.

Resumindo: se você for fazer um concurso público, eles vão cobrar um conceito de polimorfismo que é bem quadradinho (provavelmente o gabarito vai lhe declarar que é necessário ter a tal da herança).

Mas se você souber a teoria e a prática corretamente, como o Shoes, vai descobrir que o conceito de polimorfismo não está relacionado ao conceito de herança.

E por favor - todo dia nasce gente que troca as letras e diz “poliformismo”. É só lembrar que a grafia errada rima com “transformismo” (acho que você deve saber o que é um transformista, não?) e “conformismo” para saber que a grafia certa é “polimorfismo”, que é uma coisa completamente não relacionada a essas coisas.

pcalcado:

Polimorfsimo em geral:

Paper de 1985: http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf

Resumindo: existem tipos polimórficos e funções polimórficas. Sobrecarga caracteriza polimorfismo e pode ser encontrado mesmo em linguagens extremamente monomórficas.

A propósito: polimorfismo é um conceito usado em Orientação a Objetos, não da Orientação a Objetos. E OO não precisa de classes, logo não de herança como estamos discutindo aqui.

Discordo de vc. Segundo eu conversei hj com alguns professores, eles me falaram algo muito interessante:

Existem dois tipos de ligação a Estática e a Dinâmica.

Ligação Estática -> é aquilo que é definido em tempo de compilação. (EX: Item x = new Item()).

Sobrecarga é o conceito q se encaixa em ligação estática, vc consegue detectar em tempo de execução que há um método sobrecarregado.

Ligação Dinâmica -> aquilo que é definido em tempo de execução. Ex: (if(chave) return new Gato(); else return new Cachorro()

Polimorfismo entra no conceito de ligação dinâmica é aquilo que só é definido em tempo de execução, e pra existência do polimorfismo é sim necessária a existência de herança. Polimorfismo é um tipo de sobreposição de método.

Orientação Objeto se baseia em 3 coisas: Classes, Objetos e Herança, se ferir uma destas três não é considerada uma linguagem orienta há objeto.

Uma coisa que gostaria de ressaltar aqui: Há várias literaturas que falam de polimorfismo como citado no post do nosso amigo pcalcado . Os conhecedores há fundo de OO não usam estes livros pois consideram um livro mto genérico pra uma coisa que não tem nada haver com polimorfismo.

Um livro que qlq um pegar e vai matar a charada é o Livro do Jackbson de 1997 que ele fala de Polimorfismo, peguem, leiam e deem a sua opinião.

Vale ressaltar que interface é uma "casca" e não uma classe.

Só para reforçar o q eu falei, sobre o que é fundamental ter em uma linguagem orientada a Objeto, veja o tutorial da sun: http://java.sun.com/docs/books/tutorial/java/concepts/index.html

Oi,

Se seus professores discordam de Luca Cardelli (que eh um dos maiores pesquisadores da area) seria interessante voce linkar para algum trabalho que eles tenham publicado para que entendamos porque da discordancia. Preferencialmente alguma literatura que confirme com alguma base que polimorfismo soh se atinge em runtime (ligacao dinamica eh outra historia paralela a esta).

Favor linkar para uma referencia credivel. Orientacao a Objetos nao exige classes ou heranca. Uma boa referencia, em linguagem acessivel, sobre o tema: http://portal.acm.org/citation.cfm?id=324493.324538

Eu realmente sugiro que voce conheca mais sobre Luca Cardelli antes de falar algo deste tipo. Foi ele quem definiu boa parte do que sabemos sobre tipos em linguagens de programacao.

http://lucacardelli.name/

Este eh um tutorial basico sobre como java implementa OO (com classes, passagem de mensagens, etc.). Nao confundir com definicao de OO.

É esse “militarismo” que mata nas faculdades.Isso é uma especificação genérica sobre OO.E o fato de possuir essas especificações, não significa que você tenha que usar todas elas, como muito já foi dito, muitas vezes, é melhor usar Composição ao invés de Herança, e não me gosta que Java será “menos” OO por isso.

Eu queria saber quem tornou necessário associar o polimorfismo a uma ligação dinâmica?
Novamente, isso é a confusão da forma de se implementar o conceito, com o conceito em si.

É? E que tal isso aqui?
http://www.chips.navy.mil/archives/99_oct/polymorphism.htm

king_of_gods:

Discordo de vc. Segundo eu conversei hj com alguns professores, eles me falaram algo muito interessante:

Existem dois tipos de ligação a Estática e a Dinâmica.

Ligação Estática -> é aquilo que é definido em tempo de compilação. (EX: Item x = new Item()).

Sobrecarga é o conceito q se encaixa em ligação estática, vc consegue detectar em tempo de execução que há um método sobrecarregado.

Ligação Dinâmica -> aquilo que é definido em tempo de execução. Ex: (if(chave) return new Gato(); else return new Cachorro();)

O que tem a ver ligação, que varia de linguagem para linguagem, com a discussão sobre polimorfismo?

Só em tempo de execução? Então, por que uma busca no google para [google]static polymorphism[/google] retorna um mooonte de páginas (a maioria relacionado a templates do C++)?

É mesmo? Então por que uma busca no google para [google]javascript oo[/google] retorna um monte de páginas (muito mais que static polymorphism), mesmo que essa linguagem não tenha a palavra-chave class funcional?

king_of_gods:

Uma coisa que gostaria de ressaltar aqui: Há várias literaturas que falam de polimorfismo como citado no post do nosso amigo pcalcado . Os conhecedores há fundo de OO não usam estes livros pois consideram um livro mto genérico pra uma coisa que não tem nada haver com polimorfismo.

Um livro que qlq um pegar e vai matar a charada é o Livro do Jackbson de 1997 que ele fala de Polimorfismo, peguem, leiam e deem a sua opinião.

Vale ressaltar que interface é uma "casca" e não uma classe.

Quem são esses conhecedores?
E quem disse que o artigo citado pelo Shoes não fala de polimorfismo?

[

pcalcado:

Oi,

Se seus professores discordam de Luca Cardelli (que eh um dos maiores pesquisadores da area) seria interessante voce linkar para algum trabalho que eles tenham publicado para que entendamos porque da discordancia. Preferencialmente alguma literatura que confirme com alguma base que polimorfismo soh se atinge em runtime (ligacao dinamica eh outra historia paralela a esta).

Vou linkar a um trabalho, vou pedir pra eles onde foi publicado e passo aqui o link.

Dito acima.

Tá cara ele definiu, mas quem realmente pode nós orientar a isso é quem criou né?

É esse “militarismo” que mata nas faculdades.Isso é uma especificação genérica sobre OO.E o fato de possuir essas especificações, não significa que você tenha que usar todas elas, como muito já foi dito, muitas vezes, é melhor usar Composição ao invés de Herança, e não me gosta que Java será “menos” OO por isso.

Amigo você não entendeu, o que eu quiz dizer é que para uma LINGUAGEM ser OO tem que ter os três conceitos. Se você no seu programa usa ou não, não é o problema, é que ela tem q suportar os três conceitos.

Pior que isto é uma verdade… a maioria aqui sabe que existe outras maneiras de se aplicar polimorfismo que não seja atravez de herança… porem se uma questão destas cai em um concurso publico provavelmente estara assosiado com herança… caso aquele que elaborou a prova for um destes professores de faculdade multimaterias que não entende bulhufas daquilo que ensina… dai é foda…

Leonardo3001:

king_of_gods:

Discordo de vc. Segundo eu conversei hj com alguns professores, eles me falaram algo muito interessante:

Existem dois tipos de ligação a Estática e a Dinâmica.

Ligação Estática -> é aquilo que é definido em tempo de compilação. (EX: Item x = new Item()).

Sobrecarga é o conceito q se encaixa em ligação estática, vc consegue detectar em tempo de execução que há um método sobrecarregado.

Ligação Dinâmica -> aquilo que é definido em tempo de execução. Ex: (if(chave) return new Gato(); else return new Cachorro();)

O que tem a ver ligação, que varia de linguagem para linguagem, com a discussão sobre polimorfismo?

Só em tempo de execução? Então, por que uma busca no google para [google]static polymorphism[/google] retorna um mooonte de páginas (a maioria relacionado a templates do C++)?

É mesmo? Então por que uma busca no google para [google]javascript oo[/google] retorna um monte de páginas (muito mais que static polymorphism), mesmo que essa linguagem não tenha a palavra-chave class funcional?

king_of_gods:

Uma coisa que gostaria de ressaltar aqui: Há várias literaturas que falam de polimorfismo como citado no post do nosso amigo pcalcado . Os conhecedores há fundo de OO não usam estes livros pois consideram um livro mto genérico pra uma coisa que não tem nada haver com polimorfismo.

Um livro que qlq um pegar e vai matar a charada é o Livro do Jackbson de 1997 que ele fala de Polimorfismo, peguem, leiam e deem a sua opinião.

Vale ressaltar que interface é uma "casca" e não uma classe.

Quem são esses conhecedores?
E quem disse que o artigo citado pelo Shoes não fala de polimorfismo?

Eu não disse que não fala de polimorfismo disse que o conceito falando ali está equivocado.
Amigo, JavaScript não é orientada a objeto, nas últimas versões passou a suportar orientação a objeto.

Cara, baseado em que vc afirma que “JavaScript não é orientada a objeto, nas últimas versões passou a suportar orientação a objeto”?
PS: Depois de algum tempo fora da faculdade vc irá perceber que muitos de seus professores estavam equivocados.

Ok, quando você apresentar algo, qualquer coisa, a gente discute.

Errr… você pode (1)dizer qual a diferença e (2) dizer (com referências, claro) quem criou?

[/quote]
Amigo você não entendeu, o que eu quiz dizer é que para uma LINGUAGEM ser OO tem que ter os três conceitos. Se você no seu programa usa ou não, não é o problema, é que ela tem q suportar os três conceitos.[/quote]

Ele entendeu. Você que não citou nada para dar base a sua afirmação.

king_of_gods:

Eu não disse que não fala de polimorfismo disse que o conceito falando ali está equivocado.
Amigo, JavaScript não é orientada a objeto, nas últimas versões passou a suportar orientação a objeto.

As últimas versões de javaScript que eu conheço foram lançada em 1999 e 2001. De que nova versão você está falando?

Bom,

Enviei um email para um professor da UFES que trabalha e pesquisa na área de OO.

Veja o email.

Pergunta

Prezado Professor Ricardo Falbo,
Bom dia!

Envio-lhe este email para tirar uma dúvida sobre Orientação a Objeto que surgiu em alguns fórum de programação JAVA na internet.

As dúvidas que persistem são as seguintes:

• O que é Polimorfismo?
• Existe Polimorfismo sem herança?
• Sobrecarga é Polimorfismo?

Resposta

Oi André,

Realmente há muitos livros com concepções, a meu ver, equivocadas. Veja abaixo o que considero correto acerca de suas dúvidas.

- O que é Polimorfismo?

É a habilidade de um objeto assumir diferentes formas ao longo de sua vida, mudando de classe, dentro de uma hierarquia de classes.

- Existe Polimorfismo sem herança?

Não. Um objeto só pode mudar de classe dentro de uma hierarquia de classes. Ou seja, é necessário haver uma superclasse comum entre as classes. Observe, contudo, que em termos de linguagens de programação, quase sempre há uma superclasse comum a todos os objetos (tal como uma classe Object), o que permite um uso inadequado de polimorfismo.

- Sobrecarga é Polimorfismo?

Não. Sobrecarga é o fato de operações distintas terem o mesmo nome.

As respostas de cada pessoa, professor e até literaturas divergem nessas questão.

Para maiores informações, veja o capítulo 4 de minha apostila de Análise de Sistemas, disponível em http://www.inf.ufes.br/~falbo/disciplinas/analise.html

Bom segundo vocês ele está errado, pois vou da mesma concepção que ele, portanto também estou errado.

Procure pelo Ricardo Falbo e poderam conhecer um poco mais sobre ele.

Grato.

king_of_gods:

Bom,

Enviei um email para um professor da UFES que trabalha e pesquisa na área de OO.

Veja o email.

Pergunta

Prezado Professor Ricardo Falbo,
Bom dia!

Envio-lhe este email para tirar uma dúvida sobre Orientação a Objeto que surgiu em alguns fórum de programação JAVA na internet.

As dúvidas que persistem são as seguintes:

• O que é Polimorfismo?
• Existe Polimorfismo sem herança?
• Sobrecarga é Polimorfismo?

Resposta

Oi André,

Realmente há muitos livros com concepções, a meu ver, equivocadas. Veja abaixo o que considero correto acerca de suas dúvidas.

- O que é Polimorfismo?

É a habilidade de um objeto assumir diferentes formas ao longo de sua vida, mudando de classe, dentro de uma hierarquia de classes.

- Existe Polimorfismo sem herança?

Não. Um objeto só pode mudar de classe dentro de uma hierarquia de classes. Ou seja, é necessário haver uma superclasse comum entre as classes. Observe, contudo, que em termos de linguagens de programação, quase sempre há uma superclasse comum a todos os objetos (tal como uma classe Object), o que permite um uso inadequado de polimorfismo.

- Sobrecarga é Polimorfismo?

Não. Sobrecarga é o fato de operações distintas terem o mesmo nome.

As respostas de cada pessoa, professor e até literaturas divergem nessas questão.

Para maiores informações, veja o capítulo 4 de minha apostila de Análise de Sistemas, disponível em http://www.inf.ufes.br/~falbo/disciplinas/analise.html

Bom segundo vocês ele está errado, pois vou da mesma concepção que ele, portanto também estou errado.

Procure pelo Ricardo Falbo e poderam conhecer um poco mais sobre ele.

Grato.

Professores e autores de livros também erram, também ficam desatualizados, e também caem em pegadinhas. Inclusive há alguns meses atrás eu paguei um grande mico em sala de aula na frente dos meus alunos por causa de um erro que cometi, foi uma questão deste tipo, onde você percebe que o conceito que você pensava que sabia estava errado. Vivendo e aprendendo.

Livros populares que trazem conceitos errados são os maiores vilões nestes casos e existem aos montes. Esses são grandes disseminadores de desinformação e essa atinge os professores que são leitores deles assim como muitos outros. O negócio é ter uma mente aberta e sempre questionar o saber por mais inquestionável que este possa parecer.

Convide este professor para participar aqui do GUJ e ingressar nesta discussão. Em especial mostre o exemplo que coloquei no fim da página 3 deste tópico. Acredito que terá muito a contribuir para todos nós.

Na resposta do seu professor vejo que ele diz “é necessário haver uma superclasse comum entre as classes.”, tenha quase certeza que foi simplesmente porque ele se esqueceu das interfaces, algo que é comum ser esquecido e que serve como um supertipo em comum. Se você perguntar-lhe “e se eu usar interfaces ao invés de superclasses, é possível ter polimorfismo?”. Acredito que a resposta será “sim”.

Repare como esta resposta é completamente incoerente e falsa.
Um objeto não muda de classe. Isso é simplesmente absurdo.
Quem assume diferentes formas é a variável.

Vc tem duas opções:

1. Engole o que os professores lhe ensinarem e pronto e se ferre no mundo real.
2. Tem menos confiança no que eles lhe dizem e procura fontes alternativas e os coloca contra a parede.

sergiotaborda:

king_of_gods:

Resposta

Repare como esta resposta é completamente incoerente e falsa.
Um objeto não muda de classe. Isso é simplesmente absurdo.
Quem assume diferentes formas é a variável.

Vc tem duas opções:

1. Engole o que os professores lhe ensinarem e pronto e se ferre no mundo real.
2. Tem menos confiança no que eles lhe dizem e procura fontes alternativas e os coloca contra a parede.
   

Na verdade se você usar sun.misc.Unsafe (ou JNI + ponteiros em C) você consegue fazer com que um objeto mude de classe. Mas os efeitos colaterais disso…

Onde está o trabalho ou publicação utilizada como referência? Onde está a contestação de Cardelli? Desculpe mas você apenas se repetiu.

De qualquer forma, a resposta não procede. Além da já citada “mudança de classes”, que não é parte do polimorfismo em Java, JavaScript e IO têm polimorfismo e não tem classes, e aí?