Abstract class ou Interface

Abstract class ou Interface?

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?

Valeu!

O que aconselhar? Depende do caso.

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.

Entendo...

Realmente depende do caso.

É 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.

Valeu!

Talvez o melhor dos dois mundos....

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....

afe... escrevi demais.

Eu não acho que interface tenha a mesma funcionalidade que a classe abstrata.

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:

Use classes abstratas somente quando realmente não puder usar interfaces.

É 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.

Valeu!

Luiz Henrique Coura wrote:A classe abstrata pode fornecer a mesma funcionalidade da interface.

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.

[]'s

Smalltalk Membro desde: 22/11/2004 09:26:03 Mensagens: 1 Offline

Só reforçando o que o Daniel disse:

danieldestro wrote:Interface é quando você apenas quer definir um "contrato" que as classes devem realizar (implementar).

Interfaces estão mais ligadas a comportamento, enquanto que classes abstratas estão mais ligadas a implementação.

[]´s

Chovendo no molhado

Caso 1: Se sua tia Bernadete morre e a casa dela passa a ser sua, você está herdando uma propriedade.

Caso 2: Se o seu avô Josafá morre com uma dívida e você é tem que pagar, você é encarregado de fazer algo que antes não era obrigado a fazer.

Em linguagem de nerd:

Caso 1 - Herança
Caso 2 - Implementação de uma interface.

Que tosco... uhauhuahuahauahauahuhuahuha
Não gostei das analogias.
(sem ofensas)

hehehe... essa foi boa.

heheh...

puts... nerd é sacanagem!!

Olá

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.

[]s
Luca

Realmente, era isso que eu estava querendo saber.
Estou mais seguro nas modificações que fiz em um projeto no meu trabalho.

Valeu galera!

Notícias, artigos e o maior fórum brasileiro sobre Java