Eu sei como criar essas class mais não sei porque devo usa-la ,se e mais fácil cria um método porque alguém iria criar uma interface
para depois implementa seus método um método .
Se alguém puder me explica eu agradeço .
Porque um código polimorfico flexibiliza seu codigo.
Leia esse post de 9 anos atraz: http://www.guj.com.br/java/35500-programar-para-interfaces
Um dos principais beneficios, superficialmente falando, eh o seguinte:
Imagine o seguinte cenário:
public interface Veiculo(){}public class Automovel implements Veiculo {}public class Caminhao implements Veiculo {}O compilador permitira isso:
Veiculo v = new Automovel();Veiculo v = new Caminhao();… e em tempo de execução o tipo do objeto sera o da classe implementadora, inclusive, tudo o que uma interface faz, uma classe que a implementa também pode fazer.
Programar para interfaces, principalmente, expadira a capacidade polimorfica do seu codigo aumentando o reaproveitamento, a coesão e diminuindo acoplamento.
[]'s
Basicamente, a interface te abstrai de uma implementação ao definir um contrato. Exemplo:
public interface List {
public void add(Object objeto);
public void add(Object objecto, int indice);
public int size();
public void remove(int index);
// ... outros métodos aqui
}Com isso, se você precisar de uma lista em uma parte do seu código, não precisará depender de uma implementação de lista (lista ligada, lista encapsulando um array, lista sincronizada, etc.):
public void minhaOperacao(List listaDeObjetos) {
//... código da operação aqui
}Com isso, se a operação recebesse somente uma implementação de lista, digamos, uma lista ligada, você não poderia usá-la com uma lista que veio do banco de dados usando o Hibernate, já que ele utiliza outro tipo de lista. Isso cria uma cola nojenta entre o código e a implementação e, pra limparmos essa bagunça, as interfaces entram em cena.
Pense nela como um contrato. Uma interface lista define todas as operações que você pode fazer em uma lista, seja ela de qualquer tipo. Com isso você não precisa depender de apenas uma implementação e engessar seu código. A ideia de uma classe abstrata é que ela ainda não está completa, podemos dizer que uma possível classe abstrata da interface List que eu apresentei acima fosse:
public abstract class ListaAbstrata implements List {
public void add(Object objeto) {
add(objeto, size());
}
}Perceba que essa classe não implementa totalmente a interface List e, por causa disso, não podemos instanciá-la. Se você tirar a palavra-chave “abstract” do código, o compilador não irá compilar a classe, ou seja, ou implementa a interface totalmente ou declara como abstrata, dando a responsabilidade de implementar o restante da interface para as classes filhas:
public class ListaLigada extends ListaAbstrata {
//... restante da implementação
}Isso é mais ou menos o que acontece nas próprias coleções do Java. Existe uma classe abstrata que implementa parcialmente a interface List e algumas implementações herdam essa classe. Você pode ver um exemplo olhando o código da classe java.util.ArrayList. Ela herda de java.util.AbstractList.
Existem, porém, classes abstratas feitas exclusivamente para compartilhar um monte de métodos com as classes filhas, nunca faça isso. A herança é algo que deve ser usado com o maior cuidado. Eu escrevi um post sobre isso após uma longa discussão aqui no GUJ:
Valeu galera me ajudou muito com suas explicações.
Outra coisa que vale lembrar é que as classes podem ter apenas uma, e somente uma, superclasse. Mas podem implementar qualquer número de interfaces.
Você pode ter até a situação em que tem uma classe B, filha de A e gostaria apenas que B implementasse uma determinada interface.
Interfaces, portanto, são ótimas para definir fronteiras entre APIs. Por exemplo, vamos supor que você tenha uma classe que joga texto para um arquivo. Você poderia definir uma interface assim:
public DataSource {
Iterator<String> getData();
}
Sua classe seria algo como:
public class Printer {
public void toFile(DataSource data) {
//Código para enviar para arquivo aqui
}
}
Que no fundo diria: “Amiguinhos programadores. Se vocês quiserem que eu jogue os textos de vocês para arquivos, basta me dar uma classe qualquer que tem um método getData(), e que me retorne um iterator para cada linha desse texto”.
No exemplo que dei, essa classe poderia ser a classe B, que herda de A. Por exemplo, a classe A poderia ser “Componente” e a classe B poderia ser “AreaDeTexto”. Nem todos os componentes teriam texto, por isso, não faria sentido ter o método getData() em A. Mas os componentes de texto tem texto, então, faria sentido implementar a interface ali.
Você poderia dizer, “mas e se criasse uma classe entre A e B, de componentes com texto?”. Não é tão flexível. A interface ainda pode ser usada em outro contexto, como por exemplo, uma outra classe “nada a ver” como a classe de Produto, poderia querer exportar para arquivo a descrição do Produto, e implementar também a interface getData(). Veja que agora estamos falando de 2 classes de hierarquias diferentes, já que Produto não é um componente.
Note que a interface ainda é poderosa pois cria um conceito. No exemplo, o conceito das coisas que podem ser “exportadas como texto”. Você poderia criar outra classe para, por exemplo, enviar texto pela a rede, ao invés de enviar para arquivo e todos os DataSources funcionariam com ela.
Quando se inicia os estudos de Padrões de Projeto é que vemos o poder da interface, pelo menos na faculdade. Na maioria dos casos irá flexibilizar bastante seu código e também irá “protegê-lo” de alterações futuras, caso aplique os princípios SOLID e GRASP.