[quote=Luiz Augusto Prado]na classe abstrata, que pode ser a implementação de uma interface (caso que vou mostrar), pode existir um método onde todas as outras classes que a estendam a execute (sem alteração), mas que contenha em seu interior métodos que devem ser sobrescritos.
exemplo:
public interface Interface
{
public void metodoMutante();
}
public abstract class Abstrata implements Interface
{
public void metodoAbstrato()
{
// chamo meu metodo mutavel
metodoMutante(); // metodo que deve ser chamado, mas com variação dependendo de como é extendido
}
// se eu quiser um metodo metodoMutante implementado aqui, blz. Seria um genérico
}
public class Extendido extends Abstrata
{
@Override
public void metodoMutante()
{
System.out.println("oi 2");
}
}
public class main2
{
public static void main(String ags[])
{
Extendido a = new Extendido();
a.metodoAbstrato();
}
}
vejam que não preciso alterar nada em meu método abstrato.
[/quote]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface).
[quote=diogogama][quote=juliocbq][quote=diogogama][quote=douglas_arantes]
Onde eu disse que interface é uma classe abstrata? Eu disse que para obter polimorfismo pode se usar uma interface, ou uma classe abstrata.
Em c++ por exemplo não existe interface, mas você pode ter o mesmo resultado de um interface do java, criando uma classe 100% abstrata.
Acho que você ta precisando ler livros como o “design patterns elements of reusable object-oriented software”.
Até mais.[/quote]
Espera aí, vocês estão doidos??? Interface são classes abstratas??? servem para mesma coisa???
Tem o mesmo comportamento???
Eu acho que vocês devem estudar mais sobre abstração e intarfaces, pois são coisas completamente diferentes usadas para coisas completamente diferentes…
E ae Atexexe vamos acabar com as classes abstratas e interfaces também? rs…[/quote]
Diogo, interface e classe abstrata são a mesma coisa propriamente dita. Cai na mesma ladainha de método x funções.
[code]public interface Teste{
public void do();
}
public abstract class Teste{
abstract void do();
}[/code]
resolvem o mesmo problema.
Ambas são usadas para conseguir polimorfismo(a segunda pode ser implementada para complementar algum comportamento).
O pessoal que tenho visto aí é muito ligado em “terminologias”. As coisas são mais simples do que aparentam e algumas pessoas acabam complicando.[/quote]
Então quer dizer que sempre que tem que usar calasses abstratas você usa interface e está tudo certo? ou vice-versa e está certo também?
Eu acho que você deve estar viajando mesmo… você pode até achar que elas fazem a mesma coisa, ou melhor, que servem pra mesma coisa, mas não servem… Em alguns casos você pode obter o mesmo resultado com um ou com outro, porém são diferentes e já começa pelo espaço em memória que ocupam.
Dentre as várias coisas que o dsrmachado citou, pra mim, uma das mais importantes diferenças são as implementações…
Espero que não confunda mais…
Ps.: Não é apenas terminologia e sim estudo…[/quote]
[quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sem contar que só isso já seria uma grande diferença, não?
[quote=drsmachado]Aqui, aqui e aqui existem algumas informações e proposições a respeito.
[/quote]
dos que você citou:
o mais plausível seria o uso de interfaces com o design strategy, mas aí entra a questão navamente. Eu posso trocar a interface por uma classe abstrata sem problemas.
este aqui fala o que todo mundo sabe:
este aqui só reforça o meu questionamento:[quote]
As general OO terms, the differences are not necessarily well-defined. For example, there are C++ programmers who may hold similar rigid definitions (interfaces are a strict subset of abstract classes that cannot contain implementation), while some may say that an abstract class with some default implementations is still an interface or that a non-abstract class can still define an interface.[/quote]
Por isso não vejo algo que seja tão em usar interfaces ou classes abstratas(fora conseguir herança múltipla de alguma forma).
[quote=diogogama][quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sem contar que só isso já seria uma grande diferença, não?[/quote]
de vantagem, não é não. Existem muitos problemas que dá para substituir interfaces por classes abstratas. O comportamento delas é quase idêntico. A diferença ali seria ao meu ver algo como herança múltipla.
leia o link que postei e vai poder montar seus próprios exemplos…[/quote]
Diogo, você ainda não entendeu onde eu quero chegar. Eu sei o que teoricamente interfaces e classes abstratas são.
Me fala na prática onde usar uma e onde usar outra, se elas são tão diferentes.
Existe algum problema que se use interfaces que não possam ser resolvidos com classes abstratas?
[quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sim, correto. Mas no caso do metodo abstrato, vc não é obrigado a sobrescrever. Já na interface, é obrigatório.
Bem inteligente seu questionamento. Acho que o java foi feito com essas diferenças entre interface e abstract para facilitar na organização, desenvolvimento e evitar confusões. Eu faço o metodo abstract e evito com o máximo de força não altera-los.
E vc? Pra que utilizaria interfaces? Vc dá preferência por abstracts no lugar de interfaces?
[quote=Luiz Augusto Prado][quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sim, correto. Mas no caso do metodo abstrato, vc não é obrigado a sobrescrever. Já na interface, é obrigatório.
Bem inteligente seu questionamento. Acho que o java foi feito com essas diferenças entre interface e abstract para facilitar na organização, desenvolvimento e evitar confusões. Eu faço o metodo abstract e evito com o máximo de força não altera-los.
E vc? Pra que utilizaria interfaces? Vc dá preferência por abstracts no lugar de interfaces? [/quote]
Não dou preferência não. Eu sempre me perguntei isso porque meus projetos pessoais são escritos em c++ onde o conceito de interfaces não existe explicitamente. Consegue-se implementando a classe pura abstrata. Então não faz diferença. Trabalho com java, uso interfaces e classes abstratas de uma maneira em geral. Onde posso colocar um comportamento prioriso a abstrata para escrever menos e deixar o código pequeno.
[quote=juliocbq]
Diogo, você ainda não entendeu onde eu quero chegar. Eu sei o que teoricamente interfaces e classes abstratas são.
Me fala na prática onde usar uma e onde usar outra, se elas são tão diferentes.
Existe algum problema que se use interfaces que não possam ser resolvidos com classes abstratas?[/quote]
Entendi sim, porém acho que são alhos e bugalhos… Como disse, você até pode resolver uma coisa com qualquer uma das duas, mas cabe a você ver qual seria o melhor para aquele problema…
Interface tem o sentido de contrato (como todos sabem) e classes abstratas de herança… são duas coisas diferentes e para situações diferentes…
É o mesmo questionamento de “prefira composição a herança”, não é que não se resolva qualquer problema com um ou com outro, a questão é a aplicação de uma e de outra…
é praticamente a questão de usar açucar e mel, os dois dão o mesmo resultado mais cada um serve para uma solução diferente de um problema diferente…
[quote=diogogama][quote=juliocbq]
Diogo, você ainda não entendeu onde eu quero chegar. Eu sei o que teoricamente interfaces e classes abstratas são.
Me fala na prática onde usar uma e onde usar outra, se elas são tão diferentes.
Existe algum problema que se use interfaces que não possam ser resolvidos com classes abstratas?[/quote]
Entendi sim, porém acho que são alhos e bugalhos… Como disse, você até pode resolver uma coisa com qualquer uma das duas, mas cabe a você ver qual seria o melhor para aquele problema…
Interface tem o sentido de contrato (como todos sabem) e classes abstratas de herança… são duas coisas diferentes e para situações diferentes…
É o mesmo questionamento de “prefira composição a herança”, não é que não se resolva qualquer problema com um ou com outro, a questão é a aplicação de uma e de outra…
é praticamente a questão de usar açucar e mel, os dois dão o mesmo resultado mais cada um serve para uma solução diferente de um problema diferente…
Sacou?[/quote]
Nesse caso eu acho as duas muito semelhantes. E como pode ver é muito pelo contrário. Não estou dando preferência a nenhuma. Apenas dizendo que a classe abstrata implementa a interface praticamente.
[quote=juliocbq]Quero saber na prática. Qual a diferença entre elas?
Escrevi muito software usando c++ e aplicando o conceito de interfaces usando classes 100% abstratas. Por isso questiono a grande diferença entre elas no aspecto computacional e quanto ao uso de uma no lugar da outra.
Qual problema uma resolve que outra não resolveria?[/quote]
O problema que a interface resolve e a classe abstrata não resolve é implementar mais de um contrato na mesma classe. Em C++ o problema não existe por causa da herança múltipla, e por isso a solução (interfaces) também não existe.
Em Java, como por definição só pode herdar de uma classe então as interfaces resolvem a questão dos múltiplos contratos.
E aí por costume/convenção/padronização/boas práticas, usamos interfaces sempre que há necessidade de “herdar” de uma classe 100% abstrata. Em teoria seria necessário apenas quando precisasse herdar de mais de uma…
[quote=gomesrod][quote=juliocbq]Quero saber na prática. Qual a diferença entre elas?
Escrevi muito software usando c++ e aplicando o conceito de interfaces usando classes 100% abstratas. Por isso questiono a grande diferença entre elas no aspecto computacional e quanto ao uso de uma no lugar da outra.
Qual problema uma resolve que outra não resolveria?[/quote]
O problema que a interface resolve e a classe abstrata não resolve é implementar mais de um contrato na mesma classe. Em C++ o problema não existe por causa da herança múltipla, e por isso a solução (interfaces) também não existe.
Em Java, como por definição só pode herdar de uma classe então as interfaces resolvem a questão dos múltiplos contratos.
E aí por costume/convenção/padronização/boas práticas, usamos interfaces sempre que há necessidade de “herdar” de uma classe 100% abstrata. Em teoria seria necessário apenas quando precisasse herdar de mais de uma…[/quote]
Justamente. Esse é o ponto que frisei lá em cima. Mas fora isso são a mesma coisa(quando usadas para se conseguir polimorfismo).
[quote=gomesrod][quote=juliocbq]Quero saber na prática. Qual a diferença entre elas?
Escrevi muito software usando c++ e aplicando o conceito de interfaces usando classes 100% abstratas. Por isso questiono a grande diferença entre elas no aspecto computacional e quanto ao uso de uma no lugar da outra.
Qual problema uma resolve que outra não resolveria?[/quote]
O problema que a interface resolve e a classe abstrata não resolve é implementar mais de um contrato na mesma classe. Em C++ o problema não existe por causa da herança múltipla, e por isso a solução (interfaces) também não existe.
Em Java, como por definição só pode herdar de uma classe então as interfaces resolvem a questão dos múltiplos contratos.
E aí por costume/convenção/padronização/boas práticas, usamos interfaces sempre que há necessidade de “herdar” de uma classe 100% abstrata. Em teoria seria necessário apenas quando precisasse herdar de mais de uma…[/quote]
Vamos pegar exemplos práticos. Imagine se o java não tivesse interfaces, apenas classes abstratas. java.util.Comparator e java.io.Serializable não são interfaces, são abstract class.
Agora, como você faria para criar uma classe que fosse, ao mesmo tempo, Comparator e Serializable?
É neste ponto que as interfaces fazem a diferença e se diferenciam das abstract class.
[quote=drsmachado][quote=gomesrod][quote=juliocbq]Quero saber na prática. Qual a diferença entre elas?
Escrevi muito software usando c++ e aplicando o conceito de interfaces usando classes 100% abstratas. Por isso questiono a grande diferença entre elas no aspecto computacional e quanto ao uso de uma no lugar da outra.
Qual problema uma resolve que outra não resolveria?[/quote]
O problema que a interface resolve e a classe abstrata não resolve é implementar mais de um contrato na mesma classe. Em C++ o problema não existe por causa da herança múltipla, e por isso a solução (interfaces) também não existe.
Em Java, como por definição só pode herdar de uma classe então as interfaces resolvem a questão dos múltiplos contratos.
E aí por costume/convenção/padronização/boas práticas, usamos interfaces sempre que há necessidade de “herdar” de uma classe 100% abstrata. Em teoria seria necessário apenas quando precisasse herdar de mais de uma…[/quote]
Vamos pegar exemplos práticos. Imagine se o java não tivesse interfaces, apenas classes abstratas. java.util.Comparator e java.io.Serializable não são interfaces, são abstract class.
Agora, como você faria para criar uma classe que fosse, ao mesmo tempo, Comparator e Serializable?
É neste ponto que as interfaces fazem a diferença e se diferenciam das abstract class.[/quote]
Isso mesmo. No quesito de herança, pois supre a java com a possibilidade de criar múltiplas delas. No quesito polimorfismo são a mesma coisa. Como c++ permite herança múltipla eu não necessito de interfaces já que posso implementar múltiplas classes abstratas, mas é claro com cuidado para não recair no problema do diamante.
Não, não. No caso que citei não estamos tratando de herança, estamos tratando de polimorfismo. Afinal, quero que a classe que eu irei criar tenha as mesmas funcionalidades de uma Serializable (possa ser serializada) e de um Comparator (permita fazer comparações), porém, quero implementar o comportamento de forma específica (o que caracteriza o polimorfismo). A herança é apenas o caminho para isso.
Imagine que, por alguma razão, esta mesma classe precise ser uma AbstractTableModel (que é uma classe abstrata) ou estender alguma outra classe. Todo o resto está perdido, especificamente em java.
[quote=Luiz Augusto Prado][quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sim, correto. Mas no caso do metodo abstrato, vc não é obrigado a sobrescrever. Já na interface, é obrigatório.
Bem inteligente seu questionamento. Acho que o java foi feito com essas diferenças entre interface e abstract para facilitar na organização, desenvolvimento e evitar confusões. Eu faço o metodo abstract e evito com o máximo de força não altera-los.
E vc? Pra que utilizaria interfaces? Vc dá preferência por abstracts no lugar de interfaces? [/quote]
Gente, o julio está correto. Na prática, uma interface é uma classe 100% abstrata sim. As diferenças de terminologias vem das diferenças sobre como diferentes linguagens de programação implementam o polimorfismo. Não sei se vocês sabem, mas a POO é muito mais antiga que a linguagem Java. Os próprios padrões GoF são anteriores ao Java. No caso do GoF, os exemplos são mostrados com C++, e veja só, não existe uma sintaxe para definir interfaces em C++, em compensação C++ permite herança múltipla de classe. Assim o mesmo efeito de implementar interfaces do Java é obtido em C++ herdando de classes 100% abstratas.
Mas então, porque Java não fez igual ao C++ ? Para manter a simplicidade. Ao longo do tempo, a herança como é feita em C++ se mostrou supérflua (além de permitir herança múltipla, a herança pode ser public, private ou protected), leva a ambiguidades e é difícil de ser mantida. Me arrisco até a afirmar que o mantra “prefira composição a herança” veio justamente para a turma do C++ fugir da herança múltipla de classe. Ou seja, se o recurso era difícil de implementar e trazia mais problemas do que resolvia, não havia motivo para ser incluído em uma nova linguagem.
[quote=drsmachado][quote=gomesrod][quote=juliocbq]Quero saber na prática. Qual a diferença entre elas?
Escrevi muito software usando c++ e aplicando o conceito de interfaces usando classes 100% abstratas. Por isso questiono a grande diferença entre elas no aspecto computacional e quanto ao uso de uma no lugar da outra.
Qual problema uma resolve que outra não resolveria?[/quote]
O problema que a interface resolve e a classe abstrata não resolve é implementar mais de um contrato na mesma classe. Em C++ o problema não existe por causa da herança múltipla, e por isso a solução (interfaces) também não existe.
Em Java, como por definição só pode herdar de uma classe então as interfaces resolvem a questão dos múltiplos contratos.
E aí por costume/convenção/padronização/boas práticas, usamos interfaces sempre que há necessidade de “herdar” de uma classe 100% abstrata. Em teoria seria necessário apenas quando precisasse herdar de mais de uma…[/quote]
Vamos pegar exemplos práticos. Imagine se o java não tivesse interfaces, apenas classes abstratas. java.util.Comparator e java.io.Serializable não são interfaces, são abstract class.
Agora, como você faria para criar uma classe que fosse, ao mesmo tempo, Comparator e Serializable?
É neste ponto que as interfaces fazem a diferença e se diferenciam das abstract class.[/quote]
Isso é assim apenas porque Java não suporta herança múltipla. Em C++ por exemplo, seria feito exatamente com herança múltipla de classes 100% abstratas.
[quote=rmendes08][quote=Luiz Augusto Prado][quote=juliocbq]
Sim, na classe abstrata voce pode adicionar um comportamento mas no final não existe a questão da grande diferença. Nesse caso ai eu poderia extender a classe abstrata de outra abstrata(no lugar da interface). [/quote]
Sim, correto. Mas no caso do metodo abstrato, vc não é obrigado a sobrescrever. Já na interface, é obrigatório.
Bem inteligente seu questionamento. Acho que o java foi feito com essas diferenças entre interface e abstract para facilitar na organização, desenvolvimento e evitar confusões. Eu faço o metodo abstract e evito com o máximo de força não altera-los.
E vc? Pra que utilizaria interfaces? Vc dá preferência por abstracts no lugar de interfaces? [/quote]
Gente, o julio está correto. Na prática, uma interface é uma classe 100% abstrata sim. As diferenças de terminologias vem das diferenças sobre como diferentes linguagens de programação implementam o polimorfismo. Não sei se vocês sabem, mas a POO é muito mais antiga que a linguagem Java. Os próprios padrões GoF são anteriores ao Java. No caso do GoF, os exemplos são mostrados com C++, e veja só, não existe uma sintaxe para definir interfaces em C++, em compensação C++ permite herança múltipla de classe. Assim o mesmo efeito de implementar interfaces do Java é obtido em C++ herdando de classes 100% abstratas.
Mas então, porque Java não fez igual ao C++ ? Para manter a simplicidade. Ao longo do tempo, a herança como é feita em C++ se mostrou supérflua (além de permitir herança múltipla, a herança pode ser public, private ou protected), leva a ambiguidades e é difícil de ser mantida. Me arrisco até a afirmar que o mantra “prefira composição a herança” veio justamente para a turma do C++ fugir da herança múltipla de classe. Ou seja, se o recurso era difícil de implementar e trazia mais problemas do que resolvia, não havia motivo para ser incluído em uma nova linguagem. [/quote]
Claro que está, agora, a aplicabilidade de uma e de outra é diferente, de acordo com o comportamento que o java exige.
Conceitualmente, não há dúvidas que sejam idênticas, mas em java (e provavelmente C#) são diferentes, devido a detalhes específicos.