No final das contas a Abstract class fornece a mesma funcionalidade de Interface:
Interface cria uma interface para seu objeto.
Abstract class me fornece, alem dessa funcionalidade, outras coisas como operações comuns entre sub-classes.
ps: sei que isso é discussão aqui do forum faz tempo, porém não consegui encontrar uma funcionalidade para interface já que a abstract class fornece essa funcionalidade.
Interface seria para possibilitar herenças multiplas?
Enfim, o que vcs aconselham a utilizar?
Interface é quando você apenas quer definir um “contrato” que as classes devem realizar (implementar).
Classe abstrata é uma classe que (pode) fornece alguns métodos e solicitar a implementação de outros (métodos abstratos). A classe abstrata seria tbm um tipo tão genérico que não faz sentido ser criando (instanciado) no programa.
Você já deve saber que uma classe abstrata nada mais é que uma classe que não pode ser instanciada. Pois bem:
Classes abstratas:
Podem possuir atributos não estáticos
Podem implementar alguns métodos
Uma classe só pode herdar de apenas outra classe. Logo, não podemos ter uma mesma classe que herde de duas classes abstratas.
Interfaces
Não pode possuir atributos não estáticos
Não pode implementar nenhum método
Uma classe pode implementar mais de uma interface. Ou seja, possibilita boa parte dos recursos de heranca múltipla sem problemas de conflitos de nomes dos atributos.
Sugestão: Use classes abstratas somente quando realmente não puder usar interfaces.
É que estou fazendo alguns testes e vi que a classe abstrata pode fornecer a mesma funcionalidade que interface (métodos abstratos) e tb alguns métodos em comuns.
Porem vc pode fornecer o contrato da interface para classes que herdam de classes abstratas. Era isso que eu não tinha enxergado.
Exemplo, imagine uma implementação DAO (Data Access Object):
vc cria uma Interface DAO com a assinatura dos métodos básicos (insert, update e delete)
para cara Tabela ou Objeto vc implementa outra interface fazendo herança para a interface DAO, exemplo UsuarioDAO, colocando as assinaturas para as consultas de usuário (getUsuarioByCodigo(), etc)
Agora você precisa que o seu software trabalhe com Hibernate e também com SQL ou XML
Aí entra a abstração, vc cria um AbstractHibernateDAO, por exemplo, que implemente a interface DAO. Você também aproveita e pega o objeto de conexão, o de sessão etc.
Agora vc implementa a interface UsuarioHiber8DAO que herda AbstractHibernateDAO e implementa UsuarioDAO. Pronto, agora soh precisa programar as consultas.
Quando criar um ClienteHiber8DAO, vc irá herdar o mesmo AbstractHibernateDAO e implementar ClienteDAO… e aí vai.
Acho que são duas coisas distintas que podem trabalhar juntas, mas q não se substituem…
Não… é ao contrário!
A classe abstrata pode fornecer a mesma funcionalidade da interface.
Mas acho que não é bom misturar as coisas. É como o vamorin disse:
É isso que estava procurando, uma dica de quando utilizar Interface já que em alguns casos poderei tb utilizar uma classe Abstract que faz o mesmo papel.
Em alguns casos sim. Mas a principal diferença aqui é que sua classe pode implementar várias interfaces, mas estender uma única classe (abstrata ou não). Isso tem que ser levado em consideração também.
As opiniões foram todas conflitantes. Para mim as opiniões mais importantes e mais condizentes com o modo atual de encarar o desenvolvimento foram as do Vinci (vamorim).
Por que concordo com ele? Porque sou leitor do Rod Johnson que foge das classes abstratas sempre que pode. Gostaria de encontrar um post meu antigo em que reproduzi um pequeno trecho do seu livro J2EE Design and Development mas o modo atual de busca do GUJ não permitiu encontrar.
Chamar um objeto através de uma interface acarreta uma pequena perda de performance e programar por interfaces é um tiquinho mais complicado. Porém os ganhos em flexibilidade e escalabilidade mais do que compensam. Resumidamente alguns dos ganhos são:
Facilidade de mudar a implementação de uma classes sem quebrar outros componentes;
Liberdade total de implementar as interfaces sem estar preso a uma hierarquia;
Facilidade de prover implementações de teste.
Então faça como o Vinci disse: só use classes abstratas se for obrigado. Sempre que possa prefira as interfaces.
