Tenho uma dúvida.
Eu declaro um método em uma interface. A assinatura desse método diz que ele pode lançar uma exceção.
A classe que implementa essa interface implementa esse método.
Agora a dúvida: eu não sou obrigado a colocar na assinatura do método implementado que esse pode lançar a exceção. Por quê?
Se eu não coloco que ele lança a exceção que a interface diz que lança, simplesmente não posso lançá-la dentro do método (considerando que seja verificada).
[code]
import java.io.IOException;
public interface Animal {
void comunicar() throws IOException;
}[/code]
[code]
import java.io.IOException;
public class Cachorro implements Animal {
@Override
public void comunicar() {
//Não sou obrigado a colocar que esse método pode lançar uma IOException.
//Mas também não posso lançar a IOException aqui.
//Por que não sou obrigado?
}
}[/code]
[quote=marcelo.silva.java]cara vc e obrigado a colocar a exception…
[/quote]
Não sou…
Esta é uma regra geral quando se pensa em implementação e extensão em Java.
Você pode ser menos restritivo, mas não pode ser mais restritivo.
Se interface você declara a IOException e na implementação não, estará sendo menos restritivo e isso é válido.
Por exemplo, se você declara na interface que o método recebe um HashMap,
pode declarar na implementação que ele recebe um Map, pois está sendo menos restritivo.
O contrário já não é permitido, pois se alguém escreve que o método deve receber um Map na interface, e você tenta implementar ele para
receber um HashMap na implementação, podem ocorrer problemas já que outro tipo de Map pode estar sendo esperado também e o compilador não deixará isso passar.
[quote=natanaelv]Esta é uma regra geral quando se pensa em implementação e extensão em Java.
Você pode ser menos restritivo, mas não pode ser mais restritivo.
Se interface você declara a IOException e na implementação não, estará sendo menos restritivo e isso é válido.
Por exemplo, se você declara na interface que o método recebe um HashMap,
pode declarar na implementação que ele recebe um Map, pois está sendo menos restritivo.
O contrário já não é permitido, pois se alguém escreve que o método deve receber um Map na interface, e você tenta implementar ele para
receber um HashMap na implementação, podem ocorrer problemas já que outro tipo de Map pode estar sendo esperado também e o compilador não deixará isso passar.
[/quote]
Com relação à exceção eu entendi…conhecia esse princípio, mas não sabia que se aplicava a implementações.
Agora, com relação ao parâmetro do método, você não trocou? Se eu coloco na declaração do método na interface que ele espera um Map, qualquer classe concreta que implemente Map será aceito. HashMap é um Map, LinkedHashMap também. O contrário é que não se aplica. Se o método na interface declara que espera como parâmetro um HashMap, fornecer um Map gera erro em tempo de compilação, pois um Map não é um HashMap.
Na verdade viajei na maionese.
Os argumentos do método na implementação devem ser iguais aos argumentos na interface,
ou o compilador considerará como overloading e gerará um erro se o mesmo não for sobrescrito.
Você pode dar uma olhada neste link:
http://code.google.com/p/learn-java/wiki/OverridenMethod
ou no SCJP6 Study Guide da Kathy Sierra, no capítulo 2 tem uma seção sobre overriding e overloading.
Também fiz uns testes aqui para confirmar e é isso mesmo.
Desculpe o mal entendido.
[quote=natanaelv]Na verdade viajei na maionese.
Os argumentos do método na implementação devem ser iguais aos argumentos na interface,
ou o compilador considerará como overloading e gerará um erro se o mesmo não for sobrescrito.
Você pode dar uma olhada neste link:
http://code.google.com/p/learn-java/wiki/OverridenMethod
ou no SCJP6 Study Guide da Kathy Sierra, no capítulo 2 tem uma seção sobre overriding e overloading.
Também fiz uns testes aqui para confirmar e é isso mesmo.
Desculpe o mal entendido.
[/quote]
Obrigado! Ótimo link!