Uma coisa que pode te ajudar a entender quando é necessario uma interface…
pense da seguinte forma, interface representa um comportamento… vc pode ter varios objetos destintos, onde cada um destes objetos tem uma Hieraquia propia, porem pode exister um comportamento em comum entre eles, se esse comportamente te interessar essa é a hora de usar interfaces…
Por exemplo, "Fazer Som" já imaginou quantos objetos distintos podem existir no mundo que são capazes de emitir som ?? é impossivel fazer isso por herança, mais digamos que vc precise por alguma rotina, emitir o som de diversos objetos ?? como fazer ?? como ter uma sacola com uns 40 … 500 … 1000 tipos diferentes de objetos e conseguir tocar o som de todos ?? quando vc vai num aparelho de DVD o que vc procura pra tocar som ?? uma imagem + ou - assim |> akele botãozinho de play … pois é aquilo é uma interface, interface é uma forma de comunicação comum a varios objetos…
Em programação isso pode ser feito, disponibilizando um contrato por exemplo…
public interface EmitidorDeSom {
public void playSom();
}
pronto agora vc tem um contrato, uma forma de comunicar a alguem como vc interpreta que aquile objeto Emite som, ali esta o seu contrato… agora vc pode programar, de forma generica, pra tocar o som de qualquer objeto
public void emiteSomDeTodosObjetos(List objetos) {
for(Object objeto: objetos) {
if (objeto instanceof EmitidorDeSom)
EmitidorDeSom emitiSom = (EmitidorDeSom)objeto;
emiteSom.playSom();
}
}
}
o que esse método faz ?? ele pega uma lista de objetos, verifica um por um, se ele assina o contrato de EmtidorDeSom, caso positivo, ele faz um cast, do objeto, para um emitidor de som, ele simplismente esquece tudo que o objeto pode representar, e olha apenas para a interface dele de emitidor de som… nessa interface ele ativa o método
playSom() … e mesmo sem saber que objeto se trata, ele consegue emitir o seu som…
…
E agora sabendo disso… como criar um aparelho proprio ? que emite som ?? … digamos que vc seja louco e projetou um bone que emite som… vc não precisa descender o seu bone direto de um MP3 player… basta vc em seu bone que emite som, assinar o contrato de emitir som…
[code]public class BoneSomzera implements EmitidorDeSom { //implements EmitidorDeSom siginifica que vc assinou o contrato
private Color cor
private int tamanho;
private boolean aba;
private boolean couro;
//alguns métodos do seu bone
//dentro dele, obrigatoriamente, vc precisa implementar o método do contrato que vc assinou...
public void playSom() {
System.out.println("BoneSomzera começa a emitir sons malucos...");
//... pronto aqui dentro vc emite o som do seu bone....
}
}[/code]
…
Pronto, agora qualquer objeto que conheça o contrato EmitidorDeSom, pode tocar o som do seu Bone, mesmo sem conhecer o funcionamento dele, e mesmo sem obriga-lo a descender de um Tocador de som genérico… é pra isso que existem as interfaces, para Definir contratos uteis ao seu modelo (ou comportamentos uteis ao seu modelo)…
…
Um exemplo, que eu uso muito nos meus modelos é uma interface chamda Sizable eu tenho varios objetos no meu modelo que tem um referencial de quantidade, como estoque (que tem quantidade), entre varios outros objetos uteis… para ter uma forma comum de verificar o tamanho de varios objetos eu criei essa interface
public interface Sizable {
public boolean isEmpty();
public int size();
}
toda calsse no meu modelo, que tem quantidade, eu assino o contrato de Sizable, e implemento os 2 métodos… assim posso ter métodos genericos, que testam consistencia dos meus objetos, por exemplo, eu para alguns objetos, preciso verificar se ele esta vazio e se estiver, lançar uma exceção de erro, por não aceitar objetos vazio eu tenho um método na minha classe Consistences.notEmpty(Sizable obj); onde ele verifica se o tamanho é vazio e se for, lança uma exceção… isso é um exemplo pratico, que me serve, e vc pode criar os seus…
