public Integer i;
public ClasseMae() {
System.out.println("Classe Mae");
}
ClasseMae metodo(){
return null;
}
}
[/code]
[code]package pacote;
public class ClasseFilha extends ClasseMae {
public ClasseFilha() {
System.out.println("Classe Filha");
}
@Override
public ClasseFilha metodo() {
return null;
}
}
[/code]
[code]package pacote;
public class ClasseNeta extends ClasseFilha {
public ClasseNeta() {
System.out.println("Classe Neta");
}
@Override
public ClasseNeta metodo() {
return null;
}
}
[/code]
o livro diz: que metodos sobreescritos nao se pode modificar o tipo de retorno
mas como vimos ai… os metodos foram sobreescritos com sucesso… OU eles foram sobrecarregados?
Isso não modifica o tipo de retorno, afinal, classe neta “é uma” classe filha. E, da mesma forma, uma classe filha “é uma” classe mãe.
Embora ClasseFilha seja uma especialização de ClasseMae, ambas tem o mesmo tipo.
Pense no uso desse método, isso aqui é perfeitamente válido:
ClasseMae c = new ClasseFilha();
//Ok, classe filha retorna uma ClasseFilha em método
//mas como ela "é um" objeto da ClasseMae também, esse
//retorno é válido
ClasseMae m = c.metodo();
Isso aí chama-se covariância (covariant return type).
O que não seria possível é ferir a regra “é um”. Por exemplo, tentar fazer metodo() retornar uma String, ou um pai de ClasseMae.
Ou, colocando num exemplo: Se o método da classe pai só retorna pássaros, não tem problema um método na filha retornar só o beija-flor, afinal, ele é um passaro (o método só está restringindo ainda mais o tipo). Entretanto, seria um problema ele retornar um cachorro, ou então, qualquer animal - pois muitos animais não são pássaros.