já andei lendo e procurando informações sobre Interface e Classe Abstrata aqui no Fórum. Gostaria apenas que vocês me corrigissem caso minha afirmação abaixo esteja errada ou incompleta. :roll:
Interface pode possuir constantes e métodos que não possuem implementação, diferente da classe abstrata que pode possuir atributos e métodos com ou sem implementação.
A Interface tem o conceito de contrato com a classe que a implementa, devendo assim implementar todos os seu métodos.
Isso interface pode ser considerada como um “contrato” que a atesta que a classe interessada em implementar uma interface deve fornecer uma funcionalidade para todos os seus métodos (implementar). Uma interface pode possuir somente variáveis public static final (default).
Classes abstratas podem possuir métodos não abstratos (com corpo, implementação) assim como variáveis de instancia. Como diria a Kathy Sierra: “a razão de viver de uma classe abstrata é gerar subclasses”.
Lembrando que não é uma boa prática de programação escrever uma interface para colocar apenas constantes, isso não pertence ao escopo de interface, que é prover um contrato para classes que a implementam.
Para isto, faça uso de classe mesmo.[code]public class MinhasConstantes {
private MinhasConstantes() { }
public static final String NOME = "José";
public static final int IDADE = 21;
....
não sei se já comentei aqui, mas a diferença de conceito entre classe abstrata e interface, no meu ver, está mais ligado as fases de um projeto onde elas são identificadas e com seus propósitos.
Não dá pra cair no conceito puramente técnico, pois deste ponto de vista você pode optar por qualquer uma que na implementação não vai ter nenhuma limitação técnica, mesmo porque você pode utilizar a combinação das duas (o que é muito comum).
E qual a diferença então?
Interface: um contrato de implementação! É identificada numa fase onde não há necessidade de ter nenhum código implementado. Você, cliente, está acordando a interface de comunicação (métodos) com o fornecedor da implementação.
Classe/Classe abstrata: a palavra chave aqui é generalização/especialização! Normalmente identificada numa fase posterior onde você já tem algum código e ve a necessidade de generalizar certos comportamentos, alguns ficando a cargo apenas da subclasse. Isto é, vc nao quer IMPLEMENTAR o contrato, mas sim GENERALIZAR algum comportamento.
Inclusive, é por isso que implementar java.lang.Runnable ao invés de estender java.lang.Thread é mais OO, desde que você não queira ESPECIALIZAR a sua thread, mas sim IMPLEMENTÁ-LA.
Interfaces sao contratos, e contratos sao definidos durante todo o ciclo de vida do software.
Com base em que voce afirma isso? Qual o criterio adotado?
Nao ha absolutamente problema algum em implementar ou estender uma classe, linguagens puramente oo como Eiffel nem interface possuem.
Quando voce estende uma classe, esta modificando e adaptando o comportamento desta. Quando implementa uma interface esta provendo um componente que obedece ao contrato.
Implementando, voce cria “uma” runnable. Estendendo, voce muda o comportamento de uma Thread normal (open-closed principle).
[quote=Gerson]
Hm… vc entendeu mesmo o que eu disse? Mas tem certeza?
Leia de novo. Se nao entender, leia mais uma vez. [/quote]
Voce poderia explicar melhor, entao?
O que eu li foi voce afirmando que estender uma thread eh menos OO do que implementar runnable. Provavelmente eu li errado entao, pode me explicar melhor?
Imagine que você deseja definir uma NOVA funcionalidade do seu sistema, e deseja terceirizar a implementação desta funcionalidade. Pois bem, o que voce faz? Que tal começar a DEFINIR o contrato da INTERFACE? Uma vez bem definido esta interface, vc e o fornecedor podem tocar o projeto paralelamente, isto é, vc USA a interface, e ele vai tocando a implementação em cima desta mesma interface. Depois, que ele terminar, basta, através de uma factory, IoC ou o q for fornecer a instancia, certo?. (simplificando: algo como Interface i = new Implementacao()).
Concorda que na nova implementação vc nao foi direto para a implementação? E, por acaso, foi necessário ter algum código implementado para esta funcionalidade para ter conseguido definir a interface? É claro que nao! Vc deve “programar para interface”! (Já ouviu falar deste princio?) =)
No caso da classe abstrata é mais comum voce identificar numa fase posterior, quando vc já está vendo a implementação, o código! Pensando no mesmo exemplo acima, veja que o fornecedor poderia ter usado o que quisesse para implementar a interface (classe abstrata, métodos private, etc etc), desde que os métodos da interface estivessem lá, correto? Agora imagina que durante a implementação o fornecedor descobre alguns pontos de reutilização dentro do código e resolve refatorar criando uma superclasse base. Só que ele verificou tbm que alguns métodos não fariam sentido se fossem implementados nesta superclasse, e então ele resolveu deixa-los como abstratos.
Pronto! Ele criou uma classe abstrata! Agora eu te pergunto: ele teria essa mesma visão numa fase anterior quando ainda tudo que ele tinha em maos era o contrato da interface? é claro que não! A visao seria bem mais restrita! (tanto é q é por isso q desde o começo do post eu disse “normalmente”, “comum”).
E em relação a Thread x Runnable, veja bem, eu disse o seguinte:
Cada uma com sua responsabilidade!
Na maioria das vezes vc irá fornecer uma implementação, isto é, vc deseja criar uma thread implementando a interface Runnable e usar a classe java.lang.Thread somente como um meio de executar (startar). Perceba que você não quer especializar a java.lang.Thread! Não tem nada a ver com herança! Por isso usar herança aqui “não é OO”!
Por outro lado, se vc quiser especializar a classe Thread (e depois usar essa subclasse para startar suas threads que implementam Runnable), o uso de herança, na visao OO, está perfeitamente de acordo. Vc entende hein?
É isso.
Espero ter explicado melhor, senao eu desisto.
Ignorando totalmente a sua ironia ridicula e arrogante sobre os meus conhecimentos de OOP e engenharia de software duma maneira geral, a sua mensagem tem uma boa analogia, mas nada alem disso.
Interface eh a estipulaçao de um contrato, e parece-me que voce esta confundindo o conceito de Design By Contract com uma “Teoria de Gerson”, que me parece dizer que interface serve apenas para serviços em alto nivel.
Classes abstratas surgem ja com o projeto, sao uma abstraçao generalista. Evidentemente podem ser frutos de refatoraçao, bem como interfaces, metodos, atributos ou qualquer outra coisa.
Nao vou ser eu que vou te ensinar sobre DbC, porque nao me julgo competente de faze-lo e porque nao gastaria meu tempo com alguem tao arrogante. Entratanto, recomendo o livro do Meyer (ja ouviu falar nele? dica: nao eh o cara do civilization) e alguns outros volumes, tme uma lista num post: http://www.guj.com.br/posts/list/21616.java . Alguns seriam bastante uteis IMHO.
Quando eu cescer, quero ser como voce que define que algo “nao eh oo” ou “eh mais oo” sem contexto e sem se embasar em mais que uma analogia pobre.
Nao se preocupe e pode “desistir de me explicar”, deste tipo de “explicaçao” eu quero distancia. Caso alguma vez voce resolva colocar toda a sua sabedoria a disposiçao dos pobres mortais de maneira mais amena e menos senhor da verdade, estou a disposiçao.
PS.: Nao respondo mais a esta thread para nao gerar flamewar desnecessario. Qualquer duvida, meus dados de contato estao abaixo.
bom, calma, sem stress. Só acho que você concluiu muita coisa, q eu nao disse, por sua conta, e continuou concluindo inclusive nesse ultimo post… É por isso do “arrogante”, como me classificou.
Mas enfim, de qualquer forma foi mal pelo “tom” das respostas.
Depois olharei o link sim, obrigado!
Apesar de tudo, espero ter contribuido com esse assunto.
