Conteúdo muito top, estou acompanhando os videos sobre design patterns e SOLID e eles estão muito bons. Uma sugestão: fazer um projetinho end to end de alguma aplicação fazendo o uso desses padrões, pra mostrar na prática como eles poderiam ser usados em algo mais real do dia a dia.
Isso é muito bom para adicionar comportamento em bibliotecas, sem ter que exportar e ou alterar os conteúdos na pasta vendor😊. Muito bom os seus vídeos de 🎉
Booa Johnny, baita sacada!! Isso também tiraria a gente da mão dos mantenedores da Lib, dá pra gente mesmo lançar os updates internos em lib's externas sem depender deles!
A didática do Renato é sensacional! Ele consegue explicar conceitos muito abstratos de uma forma bem real e que facilitam o entendimento. Os vídeos tão sendo um material excelente para estudar
Fala Vinicius, cara valeu mesmo! E quanto a livro de PHP eu não recomendo pois o PHP nos últimos anos tem sofrido muitas modificações e tá evoluindo monstruosamente, a literatura não tem nem chance de conseguir acompanhar toda essa evolução, daí os livros ficam desatualizados muito rapidamente sacou?
Só aprendizado. Parabéns pelos conteúdos! O legal é identificar o padrão de acordo com a regra de negócio da aplicação ou do módulo. Se o processamento fossem distintos, ou seja, se um não pudesse interferir no outro, o strategy já cairia bem, ou, por exemplo, em um módulo de processamento de pagamento como já mostrado em outro vídeo aqui Enfim, parabéns novamente pelo conteúdo divisor de águas!
É exatamente isso! Eu costumo dizer que mais importante que saber aplicar o padrão de projeto é saber QUANDO aplicar o padrão de projeto! Isso é senioridade! Mandou super bem!!
@@kaizerslawte valeu mesmo pelo feedback cara, e quanto ao lance ser da NASA eu sei o quanto é osso pra aprender no começo, por isso eu as vezes repito várias vezes durante o vídeo pra ter calma pq a galera tende a entrar em pânico hahah
muito legal essa forma de apenas escrever um comentário no lugar de uma implementação alheia ao que se quer mostrar, assim deixa todo o foco no conceito. Seria legal ter falado que a ordem importa. No caso Imagem -> Watermark -> Resize e Imagem -> Resize -> Watermark tem o memso arquivo final, porém o segundo arquivo dos 3 são diferentes. Isso só importaria caso use o resultado do meio pra alguma coisa. Além disso é bom entender que a ordem também vai influenciar no tempo de execução. No exemplo, se a imagem é muito grande e a função da watermark é um O(n) por exemplo, pode ser melhor alterar a ordem e aplicar a watermark apenas no arquivo "resized". Esta também é uma grande vantagem, pois pode debugar o tempo de cada processo e medir a diferença da ordem de execução.
Fala Wallison, valeu pelo feedback, tmj!! Quanto a similaridade entre o Decorator e o Proxy, eles são mt parecidos sim, mas eles tem propósitos bem diferentes, todos dois envolvem adicionar algo a um objeto, mas com objetivos diferentes. O Decorator serve para adicionar ou modificar funcionalidades de um objeto de forma bem flexível, sem mexer na interface dele. Você vai agregando funcionalidades como se estivesse "vestindo" o objeto com novas camadas igual o exemplo que dei lá na analogia com o mundo real. Já o Proxy é mais como um "intermediário" entre você e o objeto real, dai o Proxy controla o acesso a ele. Ele é útil para situações como adiar a criação de um objeto até que ele seja realmente necessário ou para proteger o acesso a ele de alguma forma. Talvez essa semana eu consiga gravar o Proxy, ele já está nos planos pra essa playlist! Abração!
Boa!! É o que eu sempre digo, Design patterns são basicamente uso correto da Orientação a Objetos, se tu já tava seguindo esse padrão de projeto sem nem conhecer é pq muito provavelmente tu já tem um alto nível de entendimento prático de OOP
Olá! Qual seria o impedimento de fazer um ChainedImageProcessor que recebe um array de ImageProcessors e encadeia um a um, pra não ficar passando eles individualmente nos construtores? Continua uma estratégia válida?
Boa!! Nesse caso estaríamos falando do padrão Chain Of Responsibility e é exatamente isso que tu mencionou e tanto o decorator quanto o chain tem estruturas muito parecidas porém são propósitos muito diferentes, O Chain of Responsibility é como um time de atendimento que passa uma solicitação de um para o outro até que alguém resolva. Ele vai criar uma sequência de objetos onde cada um tem a chance de processar a solicitação. Se o primeiro não resolver, o próximo tenta, e assim por diante, até que alguém trate o pedido que foi feito sacou? Nessa abordagem Já o Decorator é como adicionar novos recursos a um objeto sem mudar o que ele já faz. É como se você estivesse "vestindo" o objeto com novas funcionalidades, sem mexer na essência dele e com isso a gente ganha as vantagens de conseguir trocar a ordem das coisas. O lance é que ambos envolvem passar coisas entre objetos, mas com objetivos bem diferentes! E até daria pra tentar adaptar uma troca igual tu mencionou mas se você trocar um pelo outro, pode acabar tendo mais dificuldade para controlar a adição de funcionalidades de forma flexível ou até mesmo na troca de ordem dos objetos ou na hora de ter que decidir se vai ou não vai utilizar determinadas "decorações".
@RenatoAugustoTech entendi, faz sentido. Um potencial problema que me veio a cabeça com o Decorator é a dificuldade de profiling de uso de CPU do código, pois como as chamadas do método process de cada ImageProcessor vão estar um dentro do outro da call stack, o tempo de CPU do ImageProcessor x vai ser o tempo da execução do seu próprio processamento somado com todos os outros subsequentes. Acredito que isso não seja relevante pra todo mundo, pra mim provavelmente seria, em alguns casos...
Goatei do conteúdo. Muito bom. No seu exemplo, como seria o caso se eu não quiser chamar o BasicProcessor? Pra ser bem desacoplado, eu faria assim: o Basic também deveria poder receber um Processor. Com isso, todos os processors, incluindo o Basic, precisariam aceitar um Processor nulo e teria que validar antes de executar. Nesse caso, eu tanto poderia mudar a ordem de chamada completamente, colocando o Basic num outro ponto, mas também ele poderia nem ser chamado. Você acha que está certo? Ou teria uma outra forma de fazer isso?
Então, o Decorator tem a finalidade de decorar uma classe em especifico, todas as classes decoradoras são voltadas a adicionar funcionalidade em apenas 1 classe sacou? Dessa forma que tu mencionou seria mais indicado usar o Chain Of Responsibility que é outro pattern que ainda vou gravar, abração!!
Mais um vídeo incrível! Parabéns pela simplicidade nas explicações!
Que conteúdo sensacional! Essas aulas sobre padrões de projeto valem ouro 👨💻
Parabéns...e obrigado por transmitir se conhecimento
Conteúdo muito top, estou acompanhando os videos sobre design patterns e SOLID e eles estão muito bons. Uma sugestão: fazer um projetinho end to end de alguma aplicação fazendo o uso desses padrões, pra mostrar na prática como eles poderiam ser usados em algo mais real do dia a dia.
@@MsBrunokun assim que conseguir organizar algumas coisas por aqui vou abrir algumas lives pra fazer esses live coding end to end com a turma!
Muito bom, Renato! Otima explicação. Sua didática é realmente excelente.
Isso é muito bom para adicionar comportamento em bibliotecas, sem ter que exportar e ou alterar os conteúdos na pasta vendor😊. Muito bom os seus vídeos de 🎉
Booa Johnny, baita sacada!! Isso também tiraria a gente da mão dos mantenedores da Lib, dá pra gente mesmo lançar os updates internos em lib's externas sem depender deles!
A didática do Renato é sensacional! Ele consegue explicar conceitos muito abstratos de uma forma bem real e que facilitam o entendimento. Os vídeos tão sendo um material excelente para estudar
Valeu Felipe! Fico feliz que esteja curtindo o conteúdo cara e é gratificante esse retorno!! tmj
Sensacional!!! Parabéns pelo trabalho incrível.
Valeu pelo feedback Duilio, tmj cara, Abração!!
Pô, do jeito que explicou ficou muito simples. Parabéns!
Muio bom, parabéns pelo conhecimento e pela didática!
Tmj Pedro!!
Parabéns pelo conteúdo incrível e de altíssimo nível, poderia por favor indicar um livro de PHP
Fala Vinicius, cara valeu mesmo! E quanto a livro de PHP eu não recomendo pois o PHP nos últimos anos tem sofrido muitas modificações e tá evoluindo monstruosamente, a literatura não tem nem chance de conseguir acompanhar toda essa evolução, daí os livros ficam desatualizados muito rapidamente sacou?
Só aprendizado. Parabéns pelos conteúdos!
O legal é identificar o padrão de acordo com a regra de negócio da aplicação ou do módulo. Se o processamento fossem distintos, ou seja, se um não pudesse interferir no outro, o strategy já cairia bem, ou, por exemplo, em um módulo de processamento de pagamento como já mostrado em outro vídeo aqui
Enfim, parabéns novamente pelo conteúdo divisor de águas!
É exatamente isso! Eu costumo dizer que mais importante que saber aplicar o padrão de projeto é saber QUANDO aplicar o padrão de projeto! Isso é senioridade! Mandou super bem!!
Mais uma vez, incrível o seu trabalho cara! Já ativei o sininho para sempre tá acompanhando teus videos (já até maratonei o canal hehe)
Valeu Davi! Tmj cara, Abração!
Muito brabo, ao primeiro momento parece ser da NASA para entender, porem com sua didática o conteudo é absorvido com facilidade.
Conteudo excelente!
@@kaizerslawte valeu mesmo pelo feedback cara, e quanto ao lance ser da NASA eu sei o quanto é osso pra aprender no começo, por isso eu as vezes repito várias vezes durante o vídeo pra ter calma pq a galera tende a entrar em pânico hahah
Simplesmente excelente!
Tenho uma sujestão de video. Falar sobre padrões de Annotations
Tá anotado!
Eu inclusive achei que esse vídeo fosse relacionado a annotations
@@RenatoAugustoTech tá obrigado
@@jessesantos7679 eu tava achando também
muito legal essa forma de apenas escrever um comentário no lugar de uma implementação alheia ao que se quer mostrar, assim deixa todo o foco no conceito.
Seria legal ter falado que a ordem importa. No caso Imagem -> Watermark -> Resize e Imagem -> Resize -> Watermark tem o memso arquivo final, porém o segundo arquivo dos 3 são diferentes. Isso só importaria caso use o resultado do meio pra alguma coisa. Além disso é bom entender que a ordem também vai influenciar no tempo de execução. No exemplo, se a imagem é muito grande e a função da watermark é um O(n) por exemplo, pode ser melhor alterar a ordem e aplicar a watermark apenas no arquivo "resized". Esta também é uma grande vantagem, pois pode debugar o tempo de cada processo e medir a diferença da ordem de execução.
Como de costume, excelente vídeo! Seria o Decorator um Proxy melhorado? hahaha
Fala Wallison, valeu pelo feedback, tmj!!
Quanto a similaridade entre o Decorator e o Proxy, eles são mt parecidos sim, mas eles tem propósitos bem diferentes, todos dois envolvem adicionar algo a um objeto, mas com objetivos diferentes.
O Decorator serve para adicionar ou modificar funcionalidades de um objeto de forma bem flexível, sem mexer na interface dele. Você vai agregando funcionalidades como se estivesse "vestindo" o objeto com novas camadas igual o exemplo que dei lá na analogia com o mundo real.
Já o Proxy é mais como um "intermediário" entre você e o objeto real, dai o Proxy controla o acesso a ele. Ele é útil para situações como adiar a criação de um objeto até que ele seja realmente necessário ou para proteger o acesso a ele de alguma forma. Talvez essa semana eu consiga gravar o Proxy, ele já está nos planos pra essa playlist! Abração!
Que aula incrível, obrigado!
Excelente!
Eu ja fazia meus projetos utilizando esse padrão, e eu nem sabia q existia .... kkkkkk
Boa!! É o que eu sempre digo, Design patterns são basicamente uso correto da Orientação a Objetos, se tu já tava seguindo esse padrão de projeto sem nem conhecer é pq muito provavelmente tu já tem um alto nível de entendimento prático de OOP
Olá! Qual seria o impedimento de fazer um ChainedImageProcessor que recebe um array de ImageProcessors e encadeia um a um, pra não ficar passando eles individualmente nos construtores? Continua uma estratégia válida?
Boa!! Nesse caso estaríamos falando do padrão Chain Of Responsibility e é exatamente isso que tu mencionou e tanto o decorator quanto o chain tem estruturas muito parecidas porém são propósitos muito diferentes,
O Chain of Responsibility é como um time de atendimento que passa uma solicitação de um para o outro até que alguém resolva. Ele vai criar uma sequência de objetos onde cada um tem a chance de processar a solicitação. Se o primeiro não resolver, o próximo tenta, e assim por diante, até que alguém trate o pedido que foi feito sacou?
Nessa abordagem
Já o Decorator é como adicionar novos recursos a um objeto sem mudar o que ele já faz. É como se você estivesse "vestindo" o objeto com novas funcionalidades, sem mexer na essência dele e com isso a gente ganha as vantagens de conseguir trocar a ordem das coisas.
O lance é que ambos envolvem passar coisas entre objetos, mas com objetivos bem diferentes! E até daria pra tentar adaptar uma troca igual tu mencionou mas se você trocar um pelo outro, pode acabar tendo mais dificuldade para controlar a adição de funcionalidades de forma flexível ou até mesmo na troca de ordem dos objetos ou na hora de ter que decidir se vai ou não vai utilizar determinadas "decorações".
@RenatoAugustoTech entendi, faz sentido. Um potencial problema que me veio a cabeça com o Decorator é a dificuldade de profiling de uso de CPU do código, pois como as chamadas do método process de cada ImageProcessor vão estar um dentro do outro da call stack, o tempo de CPU do ImageProcessor x vai ser o tempo da execução do seu próprio processamento somado com todos os outros subsequentes.
Acredito que isso não seja relevante pra todo mundo, pra mim provavelmente seria, em alguns casos...
Me lembrou muito o polimorfismo da POO
@@raphaelbernardino4233 porquê usa polimorfismo
Goatei do conteúdo. Muito bom.
No seu exemplo, como seria o caso se eu não quiser chamar o BasicProcessor?
Pra ser bem desacoplado, eu faria assim: o Basic também deveria poder receber um Processor. Com isso, todos os processors, incluindo o Basic, precisariam aceitar um Processor nulo e teria que validar antes de executar. Nesse caso, eu tanto poderia mudar a ordem de chamada completamente, colocando o Basic num outro ponto, mas também ele poderia nem ser chamado. Você acha que está certo? Ou teria uma outra forma de fazer isso?
Então, o Decorator tem a finalidade de decorar uma classe em especifico, todas as classes decoradoras são voltadas a adicionar funcionalidade em apenas 1 classe sacou? Dessa forma que tu mencionou seria mais indicado usar o Chain Of Responsibility que é outro pattern que ainda vou gravar, abração!!