Valeu demais@@shagost , tmj! Esse final de ano foi bastante corrido, mas 2025 vou dobrar a produção de vídeos, vai vir muita coisa bacana por aí e valeu por fazer parte disso tudo! Abração!
Cara valeu demais pelo comentário! Vai ser eleito o comentário do ano hahahah! Valeu mesmo, abração e aguarde as próximas novidades, tá vindo coisa boa pra 2025!!
Eu que agradeço@@celiovmjr ! Comentários assim que me impulsionam cada vez mais a devolver o conhecimento que um dia me ajudou tanto. Valeu mesmo pelo feedback!
Boa noite! Parabéns pelo conteúdo, sua didática é incrível e vai direto ao ponto. Renato, tenho uma dúvida sobre quando usar uma classe abstrata ou uma interface. Geralmente, opto por classes abstratas quando sei que haverá métodos úteis em comum para as subclasses. Você teria algum vídeo que aprofunde mais esse tema? Desde já, agradeço!
Fala Pierre, então, eu prefiro evitar ficar utilizando classes abstratas por conta da herança e de alguns problemas que ela pode trazer caso a gente não cuide, daí prefiro sempre seguir as interfaces e composições de objetos, eu ainda vou criar um vídeo falando sobre isso, mas tem um vídeo que eu abordo alguns riscos de utilizar classes abstratas que é no da Substituição de LISKOV, dá uma olhada lá mas pode deixar que eu vou fazer um vídeo mais aprofundado pra abordar esse tema, mas não deixe de utilizar tuas classes abstratas não, sua motivação está perfeita quanto a reutilização de métodos em comum, mas dá uma olhada lá no vídeo pra ficar atento
Faça um vídeo ensinando abstrair um mini sistema, ou uma feature, do 0, mostrando como você faz os diagramas e a sua linha de raciocínio. Isso com certeza vai deixar muito claro toda a teoria voltada na prática. Se precisar de alguma ajuda, podemos trocar uma idéia. Já te adicionei no Linkedin.
Renato, parabéns pelo trabalho. De vdd, é muito fácil entender os padrões com seus vídeos. Neste eu só fiquei com uma dúvida, na classe cliente, caso eu queira utilizar os 2 métodos de uma vez (ex.: pay e generateDocument) não seria possível, né?!
Fala Leandro, então, o código cliente precisará ser segregado também sacou? Ao invés de termos apenas 1 código pra todas as classes nós teríamos que separar eles por contextos diferentes, não sei se ficou claro mas se a dúvida permanecer me avisa que dou um jeito de te ajudar
Ótimo vídeo, mas eu tenho uma dúvida: Como você faz nas situações onde você precisa mostrar as opções para o usuário? Por exemplo, na hora do pagamento o usuário escolhe entre cartão ou pix, então pelo menos parte do seu sistema precisa ter conhecimento sobre as implementações concretas da interface, certo?. A minha ideia seria fazer uma Enum com as opções e uma Factory que retorna a implementação de acordo com a Enum passada, mas não sei se esse approach seria o ideal.
Fala Lucas, cara mandou super bem na solução, é que nesse exemplo de "pagamentos" existem diversas formas de implementar, tem gente que prefere criar código cliente separado pra cada tipo de pagamento EX: cliente seleciona no front qual o meio de pagamento ele prefere e daí o front decide pra qual rota no back encaminhar a requisição http de acordo com a esolha do cliente, então se ele seleciona Pix, a gente manda a request http pro "PixController" sacou? porém se você tiver apenas um controller nomeado como PaymentController também é super válido daí o Código cliente obrigatoriamente precisa conhecer sim as implementações concretas daí ele escolhe qual utilizará e sim a factory faz todo sentido, inclusive eu falei sobre isso no vídeo do Design Pattern Strategy e essa solução eu implementei no vídeo do Simple Factory, onde eu mostro exatamente esse lance que tu perguntou sobre o código cliente precisar conhecer as classes concretas. E pra finalizar, Sim tua solução é extremamente válida inclusive recomendada!!
Faz sentido aplicar o conceito de interface em Python, já que a própria linguagem não possui esse conceito definido? Ao criar algo parecido utilizando ABC, estaria forçando uma situação que poderia gerar problemas?
Excelente questionamento!! O que acontece é que embora o Python não tenha um conceito de 'interface' nativo como em linguagens tipadas estáticas (ex.: Java ou C#), a ideia de seguir contratos explícitos ainda faz muito sentido, mesmo em linguagens dinâmicas. O que queremos é garantir coesão e desacoplamento, e o Python nos oferece ferramentas para isso, como o módulo as Abstract Base Classes (ABC) então vai na fé pq faz todo sentido, esses principios são agnósticos de linguagem!!
Excelente conteúdo! Uma dúvida... No caso da classe Pix, faz mais sentindo, o método generateQrCode chamar uma classe QrCodeGenerator onde tem um método generate? Se sim, como ficaria a organização desses arquivos?
Isso é chamado de indireção, no caso do Pix a lógica pra gerar o QrCode poderia estar dentro do próprio método mesmo sem problemas e também sem riscos de ferir o SRP já que a responsabilidade da geração do QrCode é dela mesma, então ao tentar criar uma classe só pra gerar o qrcode a gente muito provavelmente provocaria uma indireção desnecessária dentro em vista que o método generateQrCode da classe pix só serviria pra repassar a demanda sem nenhum outro motivo pra existir
@@RenatoAugustoTech Como avaliar se devo manter o código dentro do método ou separar em uma classe diferente? Isso não está muito claro pra mim ainda. Porque ao mesmo tempo que eu entendo que irei sofrer com a o direção, eu vejo que a criação do qrcode é de responsabilidade somente do qrcode, como se fosse um service.
Excelente conteudo de novo! E eu aqui de novo pra encher o saco kkkkkk só uma duvida, no caso da classe de boleto, ela estaria "ferindo" o Single Responsability? Pois ela está "pagando" e també
Fala Wallison, hahah fica a vontade pra perguntar cara rlx, vamos lá! Quanto ao boleto ele tem sim uma responsabilidade única mesmo fazendo a geração do boleto e também o pagamento, eu sei que fica meio abstrato de entender assim pq se trata mais do contexto do que sobre código, mas tem um vídeo que eu falei especificamente sobre isso e como que a gente faz pra identificar, dá uma olhada depois na playlist sobre o video do padrão de projeto FACADE, eu expliquei exatamente sobre isso lá nesse vídeo
@@RenatoAugustoTech fechou, vou dar uma olhada lá. Essa sua série de vídeos com qualidade de edição e qualidade nos exemplos tá mto boa, to assistindo todas 👏
Conteúdo excelente! Por favor não pare, você é necessário!
Espero de verdade que vc continue por muito tempo com seus vídeos. São excelentes! 🎉🎉🎉
2025 vai vir muita coisa boa!! Inclusive quadro novo no canal!
Muito obrigado por compartilhar seu conhecimento!! Didática impecável
Excelente explicação. Parabéns pela didática!
Conteúdo fantástico. Seus vídeos estão clareando muito minha mente, vlw
Mais uma vez parabéns pelo excelente conteúdo e didática!
Da até vontade de criar um projeto do para implementar o que aprendi. 😂
Muito obrigado!
É muito satisfatório assistir um vídeo seu. Parabéns, mano.
Valeu demais@@shagost , tmj! Esse final de ano foi bastante corrido, mas 2025 vou dobrar a produção de vídeos, vai vir muita coisa bacana por aí e valeu por fazer parte disso tudo! Abração!
cara você e um dos motivos de eu continuar pagando a internet, obrigado pelo conteúdo de altissíma qualidade.
Cara valeu demais pelo comentário! Vai ser eleito o comentário do ano hahahah! Valeu mesmo, abração e aguarde as próximas novidades, tá vindo coisa boa pra 2025!!
Ótima explicação.
Você tem uma didática incrível!
Fico muito feliz por ver pessoas, que dominam o assunto, compartilhando conhecimentos.
Muito obrigado 🫡
Eu que agradeço@@celiovmjr ! Comentários assim que me impulsionam cada vez mais a devolver o conhecimento que um dia me ajudou tanto. Valeu mesmo pelo feedback!
muito bom mesmo! parabéns e obrigado pelo excelente conteúdo.
@@LuisPauloRSLima valeu Luis, tmj! Abração
sabe muito! 🫡
valeu Victor tmj!! Abração!
Boa noite! Parabéns pelo conteúdo, sua didática é incrível e vai direto ao ponto.
Renato, tenho uma dúvida sobre quando usar uma classe abstrata ou uma interface. Geralmente, opto por classes abstratas quando sei que haverá métodos úteis em comum para as subclasses. Você teria algum vídeo que aprofunde mais esse tema? Desde já, agradeço!
Fala Pierre, então, eu prefiro evitar ficar utilizando classes abstratas por conta da herança e de alguns problemas que ela pode trazer caso a gente não cuide, daí prefiro sempre seguir as interfaces e composições de objetos, eu ainda vou criar um vídeo falando sobre isso, mas tem um vídeo que eu abordo alguns riscos de utilizar classes abstratas que é no da Substituição de LISKOV, dá uma olhada lá mas pode deixar que eu vou fazer um vídeo mais aprofundado pra abordar esse tema, mas não deixe de utilizar tuas classes abstratas não, sua motivação está perfeita quanto a reutilização de métodos em comum, mas dá uma olhada lá no vídeo pra ficar atento
Faça um vídeo ensinando abstrair um mini sistema, ou uma feature, do 0, mostrando como você faz os diagramas e a sua linha de raciocínio. Isso com certeza vai deixar muito claro toda a teoria voltada na prática. Se precisar de alguma ajuda, podemos trocar uma idéia. Já te adicionei no Linkedin.
Anotado!!
Renato, parabéns pelo trabalho. De vdd, é muito fácil entender os padrões com seus vídeos.
Neste eu só fiquei com uma dúvida, na classe cliente, caso eu queira utilizar os 2 métodos de uma vez (ex.: pay e generateDocument) não seria possível, né?!
Fala Leandro, então, o código cliente precisará ser segregado também sacou? Ao invés de termos apenas 1 código pra todas as classes nós teríamos que separar eles por contextos diferentes, não sei se ficou claro mas se a dúvida permanecer me avisa que dou um jeito de te ajudar
@ muito obrigado Renato!
Ótimo vídeo, mas eu tenho uma dúvida: Como você faz nas situações onde você precisa mostrar as opções para o usuário? Por exemplo, na hora do pagamento o usuário escolhe entre cartão ou pix, então pelo menos parte do seu sistema precisa ter conhecimento sobre as implementações concretas da interface, certo?. A minha ideia seria fazer uma Enum com as opções e uma Factory que retorna a implementação de acordo com a Enum passada, mas não sei se esse approach seria o ideal.
Fala Lucas, cara mandou super bem na solução, é que nesse exemplo de "pagamentos" existem diversas formas de implementar, tem gente que prefere criar código cliente separado pra cada tipo de pagamento EX: cliente seleciona no front qual o meio de pagamento ele prefere e daí o front decide pra qual rota no back encaminhar a requisição http de acordo com a esolha do cliente, então se ele seleciona Pix, a gente manda a request http pro "PixController" sacou? porém se você tiver apenas um controller nomeado como PaymentController também é super válido daí o Código cliente obrigatoriamente precisa conhecer sim as implementações concretas daí ele escolhe qual utilizará e sim a factory faz todo sentido, inclusive eu falei sobre isso no vídeo do Design Pattern Strategy e essa solução eu implementei no vídeo do Simple Factory, onde eu mostro exatamente esse lance que tu perguntou sobre o código cliente precisar conhecer as classes concretas. E pra finalizar, Sim tua solução é extremamente válida inclusive recomendada!!
@@RenatoAugustoTech Entendi, valeu. Só pensei nessa solução porque vi seus vídeos, me ajudaram demais!!
Faz sentido aplicar o conceito de interface em Python, já que a própria linguagem não possui esse conceito definido?
Ao criar algo parecido utilizando ABC, estaria forçando uma situação que poderia gerar problemas?
Excelente questionamento!! O que acontece é que embora o Python não tenha um conceito de 'interface' nativo como em linguagens tipadas estáticas (ex.: Java ou C#), a ideia de seguir contratos explícitos ainda faz muito sentido, mesmo em linguagens dinâmicas. O que queremos é garantir coesão e desacoplamento, e o Python nos oferece ferramentas para isso, como o módulo as Abstract Base Classes (ABC) então vai na fé pq faz todo sentido, esses principios são agnósticos de linguagem!!
Excelente conteúdo!
Uma dúvida... No caso da classe Pix, faz mais sentindo, o método generateQrCode chamar uma classe QrCodeGenerator onde tem um método generate? Se sim, como ficaria a organização desses arquivos?
Isso é chamado de indireção, no caso do Pix a lógica pra gerar o QrCode poderia estar dentro do próprio método mesmo sem problemas e também sem riscos de ferir o SRP já que a responsabilidade da geração do QrCode é dela mesma, então ao tentar criar uma classe só pra gerar o qrcode a gente muito provavelmente provocaria uma indireção desnecessária dentro em vista que o método generateQrCode da classe pix só serviria pra repassar a demanda sem nenhum outro motivo pra existir
@@RenatoAugustoTech Como avaliar se devo manter o código dentro do método ou separar em uma classe diferente? Isso não está muito claro pra mim ainda. Porque ao mesmo tempo que eu entendo que irei sofrer com a o direção, eu vejo que a criação do qrcode é de responsabilidade somente do qrcode, como se fosse um service.
Excelente conteudo de novo! E eu aqui de novo pra encher o saco kkkkkk só uma duvida, no caso da classe de boleto, ela estaria "ferindo" o Single Responsability? Pois ela está "pagando" e també
Fala Wallison, hahah fica a vontade pra perguntar cara rlx, vamos lá! Quanto ao boleto ele tem sim uma responsabilidade única mesmo fazendo a geração do boleto e também o pagamento, eu sei que fica meio abstrato de entender assim pq se trata mais do contexto do que sobre código, mas tem um vídeo que eu falei especificamente sobre isso e como que a gente faz pra identificar, dá uma olhada depois na playlist sobre o video do padrão de projeto FACADE, eu expliquei exatamente sobre isso lá nesse vídeo
@@RenatoAugustoTech fechou, vou dar uma olhada lá. Essa sua série de vídeos com qualidade de edição e qualidade nos exemplos tá mto boa, to assistindo todas 👏