Orientação a objetos: Classe Abstrata VS Interface | por André Baltieri

[@haynersan]

Vamos ver se entendi: Interface é do tipo: ajoelhou tem que rezar. Ou seja, herdou TEM QUE implementar. Classes abstratas: se herdar nem precisa ajoelhar. As orações já estão prontas e você ainda PODE ou NÃO customizar suas orações. Faz sentido estas analogias?

[@baltaio]

Sim!

[@robsonsilva9490]

Cara, isso foi sensacional!

[@marcionp]

Na realidade, não se herda uma interface, mas sim, implementa-se certo?

[@diadetediotedio6918]

Na verdade classes abstratas são usadas pra definir contratos de abstração, se você herdar e não for uma classe abstrata então você tem de implementar.

[@matheusfhillypoliveiramatt2090]

adorei kkkkk

[@marcionp]

Gosto de pensar em termos de "É" ou "Sabe fazer". Sempre que algo É, uso classe abstrata. Já se algo Sabe fazer, uso interface. Não é regra mas ajuda

[@dani9153blue]

muito massa suas aulas ,ensina de maneira clara e objetiva ,muito Obrigado

[@baltaio]

🚀

[@lucasalcantara6044]

Cara, esse é o 4o vídeo que assisto sobre o assunto, fora os do curso de C# que fiz, e o seu foi o único que me fez entender. Muito obrigado e parabéns pelo trabalho!

[@baltaio]

Que bom que ajudou 💜

[@pabloleite8604]

Muito obrigado por essa didática incrível das aulas!

[@baltaio]

💜

[@danilocalixto]

Sensacional esclareceu muito bem a diferença e os exemplos práticos tornam o entendimento extremamente facilitado. Estou curtindo muito o C# cada vem mais entendendo o motivo de ser a linguagem queridinha de muitos Devs.

[@baltaio]

🚀🚀🚀🚀

[@mcmxcivviixxiii]

Balta, faz uma série explicando sobre o DDD e como utilizar corretamente essa estrutura.

[@baltaio]

DDD não está ligado a código diretamente, isto é OOP! Mas temos curso disso já => balta.io/cursos/modelando-dominios-ricos

[@robsonsilva9490]

Opa cara, tenta descolar o livro da capa vermelha que é sucesso!

[@americobila6741]

Bem explicado👌, parabéns!

[@baltaio]

🚀

[@matheusmgp1]

Show ,como sempre muito didático.

[@baltaio]

🚀

[@muriloteixeira5541]

Seus vídeos ensinando e programando me ajudam muito. Tenho 15 anos e adoro estudar programação... Muito obg pelos seus vídeos, Abraço.

[@albertolotz]

Que legal boa explicação, bom ver informações de quem tem experiência.

[@marcioalexandremarcondes557]

Muito boa explicação!

[@baltaio]

🚀

[@VictorGabriel-hw2gr]

Genial professor, muito obrigado pelo conhecimento

[@baltaio]

💜

[@leo3030100]

Top, parabéns pelo conteudo!

[@baltaio]

Obrigado 🤙

[@rvleustaquio]

Sensacional! Obrigado Balta! Abri mais ainda minha mente.

[@baltaio]

[@Cyrus_Michael]

Muito obrigado pelo vídeo

[@baltaio]

💜

[@romirantonio3736]

Parabéns André bem esclarecedor.

[@danillopinheironeto]

Balta, excelente vídeo. Senti falta dos métodos abstratos, que servem também como "contratos" a serem implementados pelos filhos que herdarem da classe abstrata.

[@Leanst.]

Bom vídeo! No caso de interfaces eu definiria como uma ótima ferramenta para objetos falaram com outros objetos com o mínimo de acoplamento. Uma outra vantagem dela é definir contratos para terceiros usarem determinados serviços de forma fácil sem você precisar expor profundezas da sua biblioteca, basta criar o objeto seguindo o contrato/doc e enviar este objeto para o usuário ( classes, objetos, APIs, etc). Outra coisa muito útil da Interface também é orientar como implementar/navegar determinados métodos e possibilidades seguindo uma 'receita de bolo' que está na definição da interface, muitas vezes, usando centenas de serviços de bibliotecas, eu não preciso conhecer tudo dela, mas uma interface me guia pelo grafo de classes até conseguir usar o serviço que preciso sem que eu necessite fazer um hack mais profundo no código alheio, claro , o programador que criou a interface tem que ter isto em mente. A interface permite manter muito mais simples a navegação pelos objetos do grafo de classes, simplificando o entendimento de regras de negócios onde (menos é mais...). Fica aí meus 50 centavos sobre Interfaces.

[@EdJastre]

Muito bom Balta, continua que tá top

[@AlexandreSpreaficoNovaes]

Top demais, agora que vi q no começo vc fala das implementacoes em interfaces 👏👏👏

[@baltaio]

hahahaha quase deu spoiler né! hahahaha

[@doctor-hook]

O pior que a forma que ele explicou é bem simplista, porque os conceitos são um pouco mais complicado. Interfaces são responsáveis por implementar "qualidade" ou "capacidade" por exemplo IRunnable obriga as classes filhas implementar o método Run. Já classes abstratas, são responsáveis por exigir que uma determinada classe tenha um comportamento preferindo ou a definir, em no caso dos métodos abstratos. Como eu disse, o buraco é mais embaixo.

[@baltaio]

🚀

[@caiocarneiro1817]

Parabéns Balta! Sempre conteúdo com muita qualidade.

[@baltaio]

Obrigado

[@marcelocorreadossantos1243]

Muito obrigado me ajudou muito a distinguir os dóis conceitos

[@baltaio]

Obrigado

[@SamuellRalph]

Parabéns, o vídeo ficou muito bom e bem didático.

[@baltaio]

[@juliocesarrodrigues9039]

Muito bom, abraço!

[@baltaio]

Não tem não :) 💜

[@DiogoSilva-mz2pe]

Vídeo muito bem objetivo, e de fácil entendimento. Muito boa suas iniciativas em disponibilizar conteúdo gratuito e de qualidade. Parabéns, e que Deus te dê forças para continuar a ajudar ao próximo.

[@baltaio]

Obrigado

[@nathanfarias591]

Excelente vídeo!!!

[@baltaio]

💜

[@joaocarlossousafe4364]

Excelente vídeo

[@baltaio]

Obrigado

[@GoriRJ]

Direto! Muito bom!

[@josuealves7929]

Show

[@baltaio]

🚀

[@murilogouvea5817]

topissimo cara

[@baltaio]

Obrigado

[@canalstartinside]

Perfeito como sempre. Balta, fala sobre Contructs e quem sabe um dia fala um pouco sobre o C# para Games como na GE Unity. Conteúdo Top!

[@baltaio]

💜💜💜💜

[@lmormilho]

Top...show...

[@baltaio]

💜💜💜💜

[@brunotdantas]

Muito Legal Balta esse vídeo. Terminei recentemente teu curso sobre fundamentos do C# e achei bem completo. Seria interessante se você tivesse um curso como o de fundamentos porém mais avançado, que ensinasse conceitos como este agora que você explicou. Valeu!

[@baltaio]

Show demais Bruno, fico feliz que curtiu! Estou produzindo o de OOP/SOLID/Clean Code e depois quero sim colocar um de C# avançado

[@priscilareboucas4348]

Muito bom !!!!

[@baltaio]

Obrigado

[@fleal07]

Muito bom...

[@baltaio]

Obrigado Felipe!

[@augustohaselein9623]

Muito boa a explicação, gostaria muito de uma explicação sobre o DDD.

[@baltaio]

Boas Augusto, temos cursos e vídeos sobre o assunto aqui no canal!

[@williamgomes3730]

CANAL BOM DEMAIS, PARABÉNS. Há um video explicando "virtual" e tbm a divisão de um projeto dentro de dotNet? Tipo, controller, infra, application..

[@diadetediotedio6918]

Balta, uma coisa importante, classes abstratas podem literalmente definir contratos como as interfaces, bastando marcar o método ou propriedade com 'abstract' ao invés de virtual. Desse modo, ele não permite implementação. A diferença de um contrato abstract pra um de interface é que o de um abstract vai agir como um contrato para um método virtual, então se você tivesse: public abstract void Pagar(); E tivesse uma classe que herda Pagamento, como uma PagamentoViaReal, você poderia fazer: public override void Pagar() {... código aqui ...} E se você depois viesse a ter uma outra classe que herda desse tipo PagamentoViaReal, como uma PagamentoViaPix, você teria as mesmas vantagens dos métodos virtuais, podendo fazer isso: public override void Pagar() { base.Pagar(); ... mais código aqui ... }

[@baltaio]

Bom dia, @DiadeTedio Tedio, muito obrigado pelo feedback 💜 Na verdade não podem... há uma similaridade entre e até uma confusão em relação a isto... Toda classe é uma implementação concreta, você tem comportamento nela, então para mockar um simples teste por exemplo, teria que ser uma interface (DIP do SOLID por exemplo). Outro ponto é que podemos implementar várias interfaces no C#, mas só podemos herdar uma classe, então não daria para seguir por exemplo o ISP do SOLID. Tem mais detalhes, mas não dá pra comentar tudo aqui.... Mas realmente, causa confusão... principalmente por que as interfaces a partir do C# 9 permitem comportamento padrão 😋... e ai? hahahahah

[@diadetediotedio6918]

@@baltaio Boa noite! Eu fico muito feliz em poder contribuir para as discussões. No caso, isso é um pouco problemático, classes abstratas não podem ser tipos concretos por definição, elas podem fornecer implementações (mesmo interfaces podem hoje em dia) e podem não ser as mais adequadas ao ISP (por não serem interfaces, de fato), assim como podem não ser adequadas ao DIP (algo que eu não sustentei), mas elas definitivamente podem definir contratos (no sentido de métodos e propriedades que precisam ser implementados por quaisquer classes filho que herdem destes). Dito isso, as interfaces são definitivamente as mais adequadas para haver decoupling.

[@jrodrigo887]

Top demais, Balta! Parabéns pelos conteúdos, estou revisitando assuntos bases que estudei na faculdade. Poderia trazer também conteúdos sobre Arquitetura Limpa. Um abraço!

[@baltaio]

Showww

[@cafeteoricotv5330]

Ótimos exemplos. Interfaces sempre foram uma pedra no meu sapato. Só fui entender mesmo quando enxerguei o porquê de usá-las. Tem um autor que diz que "interface é um ponto de variação, é por onde o software cresce". É bem complicado de entender no início. 😭

[@baltaio]

🚀

[@anderrsondiiego]

❣

[@baltaio]

🚀

[@marcosxavier641]

Balta, excelente vídeo. Na minha concepção você poderia ter trazido a explicação da palavra chave new em um método das classes derivadas. E também o que acontece se eu não usar a palavra virtual no método da classe base e override no método da classe derivada, o compilador coloca alguma palavra automaticamente? Ele define automaticamente a palavra new? Obrigado pela explanação.

[@baltaio]

Obrigado pelo feedback Marcos, mas acho que neste caso seria algo bem mais básico... para estudar o assunto Classes Abstratas VS Interfaces você já precisa ter esta base.

[@erickmaia]

Excelente tema. Me pego confuso com isso às vezes. Só tem algo do vídeo que não entendi muito bem: Aos 1:49 você diz que não podemos implementar métodos em interfaces. No entanto, aos 13:44 você implementa um método em uma interface. Simulei a segunda situação no Visual Studio, o IDE não acusou qualquer problema e compilei o código com sucesso.

[@iuryferreira8132]

Não sou o Balta, mas... o Suporte a Implementação foi adicionado recentemente a partir do C# 8, e só deve ser usado em cenários que é pertinente o uso. Normalmente (Leia-se na maioria dos casos), a interface não deve conter implementações.

[@baltaio]

Isso aí

[@ThiagoNPE]

Balta, se possível, poderia tirar duas dúvidas ? Primeiro: O que acha dessa possibilidade de implementar código na interface, indo para além do que falou no início do vídeo ? Segundo: Levando em consideração o exemplo que deu nesse vídeo, caberia o Pattern Facade para trabalhar com os diversos tipos de pagamentos ou estou pensando errado ? Obrigado pelos vídeos, muito esclarecedores.

[@baltaio]

Bom dia Thiago, como vai? Primeiro: Acho que é isto mesmo... algo mais pontual... Segundo: O padrão fachada serve para abstrair situações mais complexas. No caso você poideria ter uma fachada que esconde qual pagamento vai implementar, tomando apenas como base os dados da requisição. Agora substituir o pagamento neste cenário acho que não.

[@hemersonmilano9791]

balta, faz uma promoção do acesso anual para eu conseguir assinar seus cursos...seus cursos são muito top...parabens

[@baltaio]

Só na Black Friday agora :D

[@ARMAlexMello]

Balta, olá! Sou novo aqui em seu canal e também novo em C#. Programava em PHP quando minha área era web. Mas, se me permite, gostaria de passar uma dica sobre como explicar código para a gente, pois meu pensamento pode ser pensamento de muitos. Na orientação a objetos, a minha maior relutância foi, pra quê fazer isso se eu estou programando sozinho!? Ou seja, aquela sensação de fez e rodou o cliente não irá nem ver (então para quê eu vou criar regras para eu mesmo seguir?). Ok, forma super errada de pensar, mas, eu acrescentaria nessa explicação trechos de código que outros programadores da equipe iria fazer. Entende? Ou seja, em uma equipe grande, pelo menos na minha cabeça, o desenvolvedor sênior -que é o que mais entende das regras de negócio- que iria criar parte principal do código, como as Interfaces... os plenos e júniores é que iriam terminar de implementar. Então, quando se acrescenta hierarquia no desenvolvimento em equipe faz mais sentido a orientação a objetos. Ou, pode ser que as empresas realmente não trabalhe assim e trabalhe cada um fazendo o seu, mas, fazendo o certo. Mas quero deixar aqui que vc explica muito gostei e já gostei muito do seu canal. Parabéns!

[@baltaio]

Obrigado!

[@rochagasdiniz]

Já vi fazerem muito essa pergunta em entrevistas de emprego

[@baltaio]

hahahaha imagino!

[@nossabrunao]

Como assim a partir do C# 8.0 é possível ter implementação na Interface? Isso não interfere principalmente o S e o D do SOLID? Como vou segregar responsabilidades tendo Contrato + Implementação inclusive na mesma estrutura? Como vou depender de abstrações e não de implementações se a minha "abstração" tem implementação?

[@joaocarlossousafe4364]

Interface me parece bastante como prototipos de funções em linguagem C. void cadastrar(); void alterar(); Int main() { return 0; } // implementação void cadastrar() { //restante do codigo aqui } void alterar() { //restante do codigo aqui }

[@baltaio]

Faz tempo que não trabalho com C, mas imagino que sejam algo assim!

[@odevperovano]

Muito bom o vídeo, só não entendi qual o sentido de colocar Vencimento e Valor na interface, ela não deveria tratar de comportamentos(pagar, cancelar, cobrar etc) ?

[@eng.wandeson]

Professor, no caso eu posso criar um método de instância de uma classe e retornar isso e injetar com a interface? Ou seria melhor usar uma classe abstrata?

[@baltaio]

Consegue dar um exemplo?

[@eng.wandeson]

@@baltaio Sim! Uma classe conexão e gostaria de injetá-la dentro das outras camadas da minha aplicação de forma abstrata, ou seja, depender de uma abstração ao invés de uma instância direta. Minha ideia é criar uma classe abstrata Conection e dentro por um método que instância e retorna uma instância da classe de Conexão. A minha dúvida é: Você disse que a partir do C# 8, 9 (uso o 9) é possível usar métodos dentro das interfaces. Eu posso fazer isso dentro de uma interface ou apenas dentro de uma classe abstrata mesmo? Porque em todas as vezes que eu for usar a classe conexão, eu uso a abstração que não precisa ser instanciada e deixo tudo centralizado em um lugar só. Conseguiu compreender a ideia? Não quero depender dos container, porque posso reaproveitar o código com mais facilidade.

[@matheusvilela1637]

Qual tema vc usa Balta?

[@baltaio]

balta.io/blog/visual-studio-code-instalacao-customizacao

[@melband6720]

to penando pra aprender estes dois conceitos!

[@baltaio]

Bora!!!!

[@moacir8663]

Resumindo: interface é quando você quer definir um modelo a ser adotado por todas as classes que a implementam, e classe abstrata é a implementação de um comportamento.

[@baltaio]

Isso ai

[@nacasadobeirinha1524]

Herança é tipo legião urbana, Pais e Filhos! Ignora minha piada, achei zuado tb deixar implementar nas interfaces a partir do C#8 mas fazer o que. A intenção da classe abstrata não seria alem de deixar abstrato fazer algo Default, para que assim fizéssemos nossas subclasses. Outro ponto seria marcar o que pode ou não ser sobrescrito e acessado na classe abstrata, coisas que não nos preocupamos nas interfaces já que estamos definindo contrato correto?

[@baltaio]

hahahahah bom dia! Sobre suas pontuações, correto! São as principais diferenças!

[@thiagobasu2172]

Eu nunca entendo quando falam de interfaces no sentidos: "Elas agem como um contrato". Todo ser humano sabe o que é um contrato de serviço, contrato de alocação e etc ... mas quando se trata de programação esse termo é muito estranho!