Ola,
Heranca eh um dos pilares da orientacao a objetos, segundo a literatura (Heranca, polimorfismo, abstracao e encapsulamento). Heranca eh uma ferramenta que essas linguagens O-O te dao para te ajudar na modelagem. Utilizando-se a modelagem por heranca, ou seja, definindo seu modelo hierarquicamente, obtem-se clareza na modelagem (eh muito facil ler um modelo de classes bem projetado utilizando Heranca) e forte reutilizacao de codigo (ja que as classes filhas herdam codigo e definicoes das classes pai, evitando a reescrita de muito codigo). Por outro lado, voce ganha forte acoplamento – qualquer alteracao que voce porventura tenha que fazer nas classes pai (imagine seu sistema com muitos niveis de heranca) reflete em tooooodos que extendem daquela classe. DEpendendo do tamanho do sistema isso pode ser catastrofico. ALem do mais, a heranca em determinados casos quebra o encapsulamento – por muitas vezes, para reescrever um metodo com eficiencia em uma classe filha eh necessario conhecer detalhes da implementacao do metodo pai.
Classes Abstratas sao classes utilizadas na modelagem baseada em heranca. Sao classes que representam conceitos abstratos, genericos que nao fazem sentido serem instanciados no seu sistema e estao ali visando reutilizacao de codigo, reunindo caracteristicas que sao comuns a todos os que vao herdar dessa classe. Por exemplo… suponha a classe abstrata Motor – que tera os atributos basicos de um motor: potencia, torque, cilindros, valvulas… e os metodos ligar() e desligar().
Provavelmente voce ira definir os metodos ligar() e desligar() como abstratos. Por que? Sua classe concreta MotorCarro tem o ligar() de um jeito, sua classe concreta MotorMOto tem o ligar() de outro jeito, sua classe MotorAviao tem outro ligar(). Idem para o desligar(). Deu pra sacar? Voce esta delineando mais ou menos o seguinte: olha, no meu modelo, pra ser um motor voce deve herdar de Motor e implementar os metodos abstratos (o compilador te forca a isso). Se algum metodo for comum atodos, voce pode defini-lo na classe abstrata (seria o metodo concreto), com codigo dentro. Dai, todos que herdarem dessa classe abstrata herdadao o codigo. Como eh baseado em heranca, tem os pros e contras da mesma.
Interfaces dizem respeito a outra forma de modelar - a composicao, que eh uma alternativa a heranca. Uma interface eh basicamente o seguinte: nao tem codigo nenhum dentro, apenas atributos e assinaturas de metodos.
Meio confuso, ne ? Com composicao voce nao tem a reutilizacao de codigo – interfaces apenas definem assinaturas de metodos. SUponha o mesmo exemplo de motor – seria identico. Todas as classes que quiserem ser um Motor no modelo terao de implementar a interface motor.
public interface Motor {
public Integer valvulas = 16;
public void ligar();
public void desligar();
}
Supondo que todos os nossos motores terao 16 valvulas (esse valor pode ser sobrescrito nas classes que implementam a interface). Entao, como dizia, toda classe que quiser ser um Motor (MOtorCarro, MotorMoto etc…) tera de implementar a interface, respeitando a definicao dos metodos na interface.
Qual a diferenca, entao ?
COmo disse, sao 2 formas de modelar – com suas vantagens e desvantagens. O uso de interfaces nao produz o problema de quebra de encapsulamento visto que as implementacoes nao herdam nada de classes-mae, porem nao tem a reutilizacao do codigo com a facilidade que a heranca da. Basicamente, uma interface define um comportamento 100% abstrato, deixando a responsabilidade da implementacao total para o programador.
Se ficou confuso, basta dizer que tento explicar melhor.
Abs!!