Boa tarde pessoal ! Estou com uma dúvida que não consigo entender muito bem. Qual a diferença entre a classe abstract e a interface? Poderiam me explicar de forma bem resumida, se não pedir demais, com alguns exemplos…
Desde já, agradeço !
Nao esquece de ler sobre Interfaces Funcionais do Java8 … 
Ontem mesmo tive uma aula sobre isso.
apenas digo:
Classes abstratas estão entre classes comuns e as Interfaces, uma classe abstrata possue apenas alguns métodos abstratos.
Se todas as suas classes forem abstratas vc deve fazer uma Interface.
Se houver algum método abstrato , sua classe deve ser abstrata!
Classes abstratas não são instanciadas, ou seja não se usa o NEW na hr de chamar.
Primeiro, para entender o que é uma classe abstrata ou uma interface, devemos entender o que é um método abstrato. Um método é abstrato quando ele não fornece implementação. Ele não tem corpo, e termina em um ponto-e-vírgula:
void fazAlgo(); //é assim que um método abstrato aparece em uma interface
public void abstract fazAlgo();//é assim que um método abstrato aparece em uma classe abstrata.
Um método abstrato deixa a responsabilidade da implementação (ou definição, ou seja, o corpo do método) para as classes que extenderem/implementarem o tipo onde ele é declarado.
Uma classe abstrata tem as seguintes características:
-
Não pode ser instanciada. Ela pode ter construtores, mas estes devem ser invocados pelas subclasses. você não pode invocar new [nome do construtor] diretamente em um construtor de uma classe abstrata. Esta é a definição básica de uma classe abstrata: uma classe cujos construtores só podem ser invocados por subclasses dela.
-
Uma classe abstrata pode conter um ou mais métodos abstratos (Não é necessário que contenha, mas geralmente, é pra isso que queremos uma classe abstrata). Ela serve para implementar parcialmente uma funcionalidade.
exemplo:
public abstract class Shape
{
private int x;
private int y;
//construtor. Não pode ser invocado a não ser por subclasses.
public Shape(int x, int y)
{
this.x = x;
this.y = y;
}
public int getX()
{
return x;
}
public int getY()
{
return y;
}
public void move(int newX, int newY)
{
this.x = newX;
this.y = newY;
}
//para casa tipo de forma, este método deve fornecer uma definição
//ou seja, toda subclasse de Shape deve implementar este método ou
//ser declarada como abstract também.
public abstract void draw();
}
uma interface só possui métodos abstratos e públicos (e portanto, os qualificadores public e abstract são ilegais quando se declara um método de uma interface). Nenhum método fornece uma implementação (salvo pelos métodos qualificados com a nova palavra reservada default, que serve para manter a compatibilidade entre as versões antigas do Java e a versão 8. Não declare métodos default em sua interface, a menos que seja por motivo de compatibilidade. Se você pretende fornecer uma implementação a um ou outro método, use uma classe abstrata).
exemplo:
public interface IDrawable
{
void draw();
}
Bem, “de forma bem resumida”, como vc pediu, é isso aí.
2 curtidas
Bom dia brother. Quero agradecer antes pela resposta sua e seu exemplo !!
Então… A classe que implementar uma interface, tem um contrato a ser feito com a interface, ou seja, uma obrigação de implementar tudo que há nela, claro que a classe ainda tem a responsabilidade de implementar os métodos com funcionalidades, definições distintas, como também ocorre em uma classe abstract certo?
E a classe que herdará uma classe abstract “pode” implementar seus métodos, não existindo contrato?
Eu estou com uma dificuldade em relação a saber a real funcionalidade de cada uma.
Obrigado desde já , mesmo q eu tenha algumas dúvidas, é que esta difícil de fixar isso pra mim 
kkkkk !
A classe que implementar uma interface pode ser abstract, e assim pode não implementar todos os métodos. Mas apenas uma classe concreta pode possuir uma instância. Outro exemplo:
Vamos levar em consideração o polimorfismo. Imagine que você está projetando um player de áudio, e que você cria uma interface IAudioFile, que possui os métodos play, stop, pause e seek, decode.
Agora imagine um arquivo de áudio no HD. uma sequência de zeros e uns que, dependendo de seu formato, é interpretada de uma certa forma pelo player. Certo. Vamos dizer que existem dois tipos básicos de arquivos de áudio, cada um deles usando um tipo diferente de compressão. Em todo o resto esses dois tipos de arquivos são idênticos.
Então você cria uma classe abstract chamada AbstractAudioFile que implementa IAudioFile. Nesta classe você coloca todas as funcionalidades necessárias para ler e processar os dois tipos de arquivos de áudio como streams de bytes, implementando os métodos de IAudioFile mas você não implementa o método decode, que transforma o arquivo físico em seu HD no stream de bytes que seu player usa. Essa classe faz basicamente tudo que é necessário pro seu player, além dos métodos da interface, ela tem diversos outros métodos importantes para o processamento correto do stream de bytes em seu player.
Então agora, para cada um dos dois tipos de arquivos físicos que eu mencionei, que usam modos de compressão diferentes, você cria uma classe concreta que extende AbstractAudioFile. Nessas duas classes concretas, a única coisa que falta implementar é o método decode, que permanece abstrato, e que depende do tipo de arquivo. Você implementa o método decode de acordo com o tipo de compressão que cada arquivo usa e pronto.
Agora seu aplicativo aceita uma lista de IAudioFiles como playlist. Seu aplicativo não precisa saber que tipo de arquivo cada música na playlist é. Ele apenas invoca polimorficamente (ou virtualmente) os métodos que ele sabe que todos os IAudioFiles tem: play para tocar a música, stop para parar, pause para pausar, seek para escolher uma posição na música e decode para carregar o arquivo do disco para seu aplicativo.
Para uma classe ser concreta, ela tem de implementar todos os métodos abstratos que ela herda, senão ela será uma classe abstrata também (como AbstractAudioFile, que herda os 5 métodos de IAudioFile, mas só implementa 4, e portanto, é abstract).
Imagine o mesmo cenário mas que agora você quer extender seu aplicativo para que ele possa processar dezenas de outros tipos de arquivos de áudio. Tudo que você precisa fazer é criar uma classe concreta para cada tipo de arquivo de áudio, contendo apenas a implementação do método decode. O resto todo (que pode ser muita, muita coisa mesmo), AbstractAudioFile faz. E seu aplicativo não precisa nem saber que você acrescentou suporte a outros tipos de arquivos de áudio, afinal ele apenas lida com IAudioFile, e apenas invoca os métodos dessa interface. Em tempo de execução, cada IAudioFile na playlist do seu aplicativo pode ser de um tipo diferente, e o método decode correspondente de cada um vai ser invocado polimorficamente quando seu aplicativo invocar o método decode da interface. Ele não sabe como o método faz o que faz, apenas sabe que o método cumpre o contrato.