Boa noite pessoal,
![:coffee: :coffee:](https://www.guj.com.br/images/emoji/twitter/coffee.png?v=9)
Atualmente estou estudando Java, e em uma das aulas foi apresentado as classes abstratas e interfaces. Entendi o conceito e já fiz alguns testes também com ambas. A diferença que percebi foi a declaração de variáveis nas classes abstratas (que não é possível nas interfaces), e a possibilidade de implementar mais de uma interface em uma classe (o que não é possivel em subclasses).
Então fique pensando se não seria melhor trabalhar apenas com a classe mãe e definir os métodos abstratos, e interfaces só seriam interessantes quando fossem necessário implementar mais de uma?
A dúvida que eu tenho é a seguinte, em quais casos seria melhor implementar classes abstratas do que interfaces e vice-versa? Se puderem compartilhar alguma experiência de vocês que foi melhor usar um do que o outro, serei grato! ![:grinning: :grinning:](https://www.guj.com.br/images/emoji/twitter/grinning.png?v=9)
![:pray: :pray:](https://www.guj.com.br/images/emoji/twitter/pray.png?v=9)
Oi @WillianC19,
Uma referência que gosto muito para esse tipo de pergunta é o livro Effective Java do Joshua Block.
Aqui um post (baseado no livro) sobre essa questão: https://dev.to/kylec32/effective-java-tuesday-prefer-interfaces-to-abstract-classes-21cn
Da minha própria experiência, é bem comum eu criar interfaces mas não lembro a última vez que eu usei uma abstract class.
2 curtidas
Os materiais do Robert Cecil Martin (Uncle Bob), autor do “Código Limpo” e “O Codificador Limpo”, também explicam a flexibilidade que as interfaces proporcionam ao contrário do acoplamento forte que ocorre com herança de classes.
Dê uma lida nos materiais dele, disponíveis nesta página.
1 curtida
Na maioria dos casos nao precisa usar ambos. Só adicione complexidade se realmente precisar. Classe abstrata gera amarrações e interface gera burocracia quando não há necessidade de um contrato. Só com experiência real vai saber quando usar ou nao, eu evito o máximo ambos. Ambos sao mais pra requisitos nao funcionais que já usamos pronto de frameworks. Pro Negócio que é muito dinâmico raramente uso.
1 curtida