Ai galera no livro Kathy diz que esse tipo de sobrescricao com retorno Convariante é valido para java 1.5 !pag 75 para quem tem o livro 2 edicao
mas ao compilar nao da certo 
class A{
void go(){}
}
class B extends A{
String go(){
return null;
}}
alguem tem uma luz? :shock:
Mas String nao é covariante com void!! A sua classe A precisaria, por exemplo, retornar Comparable, CharSequence ou Object para que a reescrita devolvendo String compilasse! Exemplo
class A{
Object go(){ return null; }
}
class B extends A{
String go(){
return null;
}
}A regra é:
Um método de uma classe poderá ter um tipo de retorno que é uma subclasse do tipo de retorno de seu pai.
No seu caso, como falou o Paulo, String não é filha de void. Portanto, não poderia ser um retorno covariante.
String é filha de Object, CharSequence e Comparable. Por isso, o método do pai teria que ser alterado para que houvesse covariancia.
E para completar veja o seguinte… a regra de subscrita disse que vc tem que manter o tipo de retorno ou no caso de java 1.5 retorno covariantes… mais nesse seu caso nao acontece nenhum nem outro… e também nem é uma sobrecarga… vc so pode usar retorno covariante aquilo que que passar no teste É-UM. tirando isso vc pode descartar veja:
class Animal{
Animal pata(){return null;
}
}
class Dog extends Animal{
Dog pata(){
return null;
}
}Veja ai que dog para no teste É-UM e por isso que a subscrição funciona com retorno covariantes disponivel a partir do java 1.5.
flw!
Fabio,
É só um erro do livro (acho que a versão em inglês está correta). É só entender a idéia que o pessoal explicou.
[quote=J2Alex]Fabio,
É só um erro do livro (acho que a versão em inglês está correta). É só entender a idéia que o pessoal explicou.[/quote]
ok agora to sussegado!!é um erro mesmo,valeu
[quote=ViniGodoy]A regra é:
Um método de uma classe poderá ter um tipo de retorno que é uma subclasse do tipo de retorno de seu pai.
No seu caso, como falou o Paulo, String não é filha de void. Portanto, não poderia ser um retorno covariante.
String é filha de Object, CharSequence e Comparable. Por isso, o método do pai teria que ser alterado para que houvesse covariancia.[/quote]
ok beleza essa entendi mas minha duvida é pq justamente no livro esta errado entao mas valeu!
qual a sua edicao? eu encontrei esse erro na edicao 1… nao lembro dela na edicao 2.
Eu tenho a 2 edição e o erro tambem consta ali …
A editora deve ter achado void covariante de String …
Qual classe seria covariante de void ?
Olha… não sabia disso.
Também acho que nunca precisei usar algo assim.
Nenhuma.
Como eu disse no ano passado, você só tem covariância se a sua subclasse retornar um filho do tipo de retorno do método na superclasse. Como nada é filho de void, não existe covariancia para esse caso.
kkkk valew …
falta de atenção a minha …
Começei a estudar semana passada …
Aproveito que o meu trampo é mto sussa …
Estudo umas 6 horas por dia de segunda a sexta …
Pretendo fazer a prova no meio do ano (Seje o que Deus quiser kkkk)
Mas consegui entender essa questão de retornos covariante …
Caro amigo Denys20 acho que houve um equívoco da sua parte meu caro. O livro está correto sim… só que o livro fala (neste exemplo) do caso de método sobrecarregado. E o próprio livro diz que haverá um erro. (Veja os comentários do próprio livro). Erro em tempo de compilação.
public class Foo{
void go(){ }
}
public class Bar extends Foo{
String go(){}//Error here!!!
return null;
}Por tanto o livro está correto por que ele fala de sobrecarga e não sobrescrita… como disse: Acho que você se equivocou!
Jacobis, por favor, evite ressuscitar tópicos muito antigos sem um bom motivo para isso.
Além disso, ao fazê-lo, não responda o tópico como se a dúvida tivesse sido postada ontem. Deixe claro que você está ressuscitando o tópico e o porque.
Será que já não houve uma correção no livro? Afinal, são 3 anos de diferença entre o tópico original e sua resposta…
Vini meu caro, foi mal aê! Não tinha visto! Mas mesmo assim aproveitando o ensejo o erro foi corrigido na versão 3. :lol: