Muito bom. Trabalho a anos dando manutenção em códigos legado. As estruturas if.. Elseif ou Case .. when... São muito comum. O problema maior, é tempo e teste. Mas essa abordagem é muito boa, e melhora o entendimento do que a rotina faz. Legal
Acabei utilizando este padrão por aplicar os princípios do SOLID. Sabia da existência desse pattern, mas não compreendia o conceito em si. Mais um excelente video.
O que me chamou atenção neste vídeo foi que, quando eu conheci esse canal tudo era estranho e não entendia nada, mas olhava tudo mesmo assim, hoje as coisas fazem sentido e acompanho o assunto entendo e imaginando a usabilidade do tema em diferentes projetos. Adoro o canal!
Gostei do conteúdo de vocês. É fácil de entender e tira toda a complexidade que os nomes causam na cabeça da pessoa quando está tendo o primeiro contato. Parabéns!
Muito bom o vídeo. Bem esclarecedor e explicado de forma muito simples. Minha sugestão sim, com certeza, seria que se possível que vocês produzissem, uma série com os demais patterns seria ótimo! Venho estudando sobre design patterns a agum tempo já, e claro, sempre é bom rever os conceitos e a partir de diversas perspecitvas. E além do mais, gostei muito da explicação de vocês, acho que funcionaria bem com outros patterns também. Parabéns!
Oi!! Muito bom o vídeo, e a incrível coincidência é que eu também estava criando um tutorial sobre Strategy (na verdade era mais voltado ao uso prático de Interfaces) e ficou bem parecido com o vídeo de vcs, só que no meu caso, o contexto era um carro e as implementações eram pros tipos de combustíveis na hora de abastecer! O vídeo de vocês ficou perfeito, seria muito bom se vcs explicassem outros patterns na prática, com a essa didática, acredito que desmistificaria esse assunto que por vezes poder ser tão complexo. No mais, excelente vídeo, aguardo por mais assim! Até.
Sim, e mais ou menos, porque todo design de composição tem essa "essência". O strategy tem mais o objetivo de composição comportamental, onde o objetivo é alterar o comportamento de acordo com a classe instanciada, dentro da subclasse, implementando uma interface comum.
Curti! Bom saber que eu já programava assim mesmo sem saber que o nome do padrão de projeto é "Strategy". Se fizerem uma série de implementação de padrões de projeto com certeza seria muito legal.
Muito bom, obrigado pela iniciativa. Tenho que confessar que o Gabriel me lembra o tíbio (ou o perônio?) do castelo ra-ti-bum. Interprete como um elogio. Sucesso pra vocês.
Sensacional a didática que vocês utilizam, uso diariamente o PHP e a aplicação do método é incrível e facilita demais o trabalho, principalmente quando falamos de manutenção!! No entanto, o mundo da programação precisa muito desse incentivo ao uso de design pattern, pois vejo que há muitos profissionais e sistema legados que ainda esbarram em grandes dificuldades na manutenção do código, justamente por não terem evoluído no uso de estratégias e padrões de codificação como esta. Como vocês veem a situação de sistemas legados que muitas vezes obedecem regras próprias (oriunda da mente de cada programador envolvido) e a aplicação das novas metodologias? Acredito que daria um excelente vídeo, fica a aí a sugestão. Abraço
Estou lendo justamente o livro "Usando a cabeça, Design patterns" e o "Dive into Design Patterns", complementando com o Refactoring Guru. Conteúdo certeiro.
Eu estava só ouvindo e de repente o Gabriel "vai dar mais manutenção", e eu "hein?!?!?!?". KKKKK Voltei e fui assistir de volta, aí que vi que tinha a correção. Excelente conteúdo, como sempre.
Poderiam abrir, para enviar soluções utilizando outras linguagens e montar um hub de exemplos, seria bem legal, no momento estou estudando patterns e realizando vários tests!! Obrigado vocês são show
Acho que migrar para outras linguagens fica como desafio para o próprio developer, pois o padrão é inerente à liguagem. Eu já segui uma playlist de design pattern de outro canal e o professor utilizou TypeScript. Eu sempre concluía com TypeScript e depois fazia em Java, Python, PHP e C# por conta própria, para testar a minha assimilação do conteúdo.
Muito obrigado pelo conteúdo, excelente! ❓Fiquei com uma dúvida, qual seria a abordagem para selecionar a classe de FreteServico dinâmicamente? Para eu não ter mais um monte de if para definir qual classe devo utilizar.
Amei a explicação. Amo o canal de vcs. Uma coisa ainda sobre o strategy que eu gostaria que comentassem, se possivel. No código sem strategy havia uma forma de identificar qual era o calculo de frete a ser utilizado, porém no código com strategy isso simplesmente não apareceu. Em outras palavras.. em algum lugar aquele monte de ifs vai ter que existir, estou errado? Obrigado!
Ótimo conteúdo e incentivo de Design Patterns, precisamos muito disso! Acrescento ainda o uso dos métodos mágicos __get() e __set() do php (www.php.net/manual/pt_BR/language.oop5.overloading.php#object.set), com eles não é necessário implementar "getters" e "setters" para cada atributo privado da classe, deixando ainda mais dinâmico e limpo esse tipo de implementação no php. Valeu!
O conceito está muito bem explicado e eu já o conhecia, mas sempre que vejo esse pattern me surge a seguinte dúvida: como é a melhor forma de escolher qual objeto de serviço instanciar? Na minha limitada ótica teriam vários IFs determinando qual classe de serviço instanciar com base na opção escolhida em tela pelo usuário. No exemplo, vocês fizeram "Hard code" essa escolha (Sedex, DHL... ) , mas em uma aplicação real provavelmente a escolha viria do usuário e não daria pra escapar dos IFs ou case. Mesmo usando um factory, entendo que em algum lugar vai ter que ter essa "sujeira". Ou estou enganado?
Sim, infelizmente Neste link abaixo, explica sobre o estrategy e eles colocam um exemplo de uma aplicação real instanciando as classes e é utilizado os ifs refactoring.guru/design-patterns/strategy
Você pode usar um dictionary com a opção de escolha como chave e a classe da estratégia como valor e implementar um método método seleção baseado na escolha do usuário.
pergunta de qlqr forma não teria algum ponto do codigo q teria q ter um monte de if, por exemplo, o lugar onde vai instanciar essas classes q agora vc passa para o Frete?
Video muito bom, parabéns!!! Gostaria que fizessem um video sobre o design pattern Factory, de preferência não em JS, já tem muito material desse pattern para JS. Poderia sem em python, php ou qualquer outra linguagem.
@@codigofontetv Uma sugestão de linguagem: C# (ou qualquer outra orientada a objetos) pq no JS eu até entendo a necessidade desse pattern, mas em linguagens ''mais'' POO eu enxergo esse pattern apenas como um construtor de classe, então seria bom ver esse pattern sendo explicado em alguma linguagem que trabalhe com esse paradigma por padrão.
Seria interessantíssimo uma série falando só sobre design patterns. São conceitos que, independente da linguagem, são muito úteis para a manutenção do código.
mas o código sem Strategy esta com varios IFs enfileirados. Ja no codigo com Strategy nao tem nenhum If ou switch para validação. nesse caso, o uso de IF ou switch é inevitável ?
E se no seu sistema tivesse a funcionalidade em escolher qual transportadora gostaria de calcular o frete, como ficaria este exemplo? Iria utilizar outro Design ?
No caso que o frete venha da tela por exemplo, tipo de frete (Sedex, Pac, Jadlog), vou continuar tendo que ter o IF para saber qual serviço eu devo passar não? No cenário de vocês já sabem qual o pagamento deve ser utilizado.
Amigos, olá! Primeiramente parabéns pelo vídeo! Minha questão é a seguinte: numa primeira situação, imaginemos que o mercado livre utiliza para o seu cálculo de frete apenas a cubagem Quebra o contrato inicial de peso Em outra, imaginemos que a hdl e mais duas passam a utilizar também a cubagem para calcular o frete. Acredito que mexe em todas as implementações, isso? A classe cheia de ifs acredito que teria mais rapidez em fazer este ajuste será?
o strategy tem similaridade com os padrões bridge, adapter e state, que apesar de terem sido criados para resolução de problemas diferentes, tem conceitos muito parecidos. Entendem um, automaticamente você compreenderá os outros. Além disso, esses padrões tem algo em comum: SOLID
achei legal o vídeo mas ainda não entendi onde rola a substituição dos IFs... parece que foi redirecionado ao cliente ao invés da classe que detém o contrato. A intenção foi essa?
Se alguns serviços desses precisassem de mais alguma infomação para calcular o frete, por exemplo: altura, largura, etc Esses dados seriam colocados na assinatura do método da interface Strategy calcular(peso, largura, altura) certo? E ai os serviços que não precisam da informação simplesmente não usam a mesma certo? Ou nesse caso por não se aplicaria o Strategy?
Olá! Gosto muito dos vídeos que vocês postam, sempre são muito relevantes. Eu fiquei com uma duvida quando à esse vídeo. Esse não seria um Padrão Factory? Por que pelo me parece uma Factory com inversão de dependência. Se não não for, porque é um Strategy e não Factory? Obrigado ! =D
A factory ela apenas cria o Objeto e a Strategy ela executa uma ação... Main -:> class factory -> main ......... Main -> class Strategy ..... strategy é mais utilizado quando vc quer fazer uma serie de coisa além de executar uma ação do objeto que não é responsabilidade da main.
8:00 kkkk "Implementando frete do MercadoLivre... Fazendo previsão do futuro? Gente isso é tudo de mentira... Não precisa nem avisar... " Acertooooo, hehehehe Eu chegando 2 anos depois e acho essa pérola de premonição. Muito bom!
Olá, excelente vídeo... no próprio vscode tem ferramenta para fazer testes de apis que substituem postman e insomnia. Faça uma busca por http no marketplace.... eu uso humao.rest-client.
Teria alguem me ajudar ... no momento em que ele codifica essa parte $frete = new \Services\Frete($sedex); echo $frete->calcula(10); ele esta chamando a Interface ou a função que esta na classe Frete ? ou o context é obrigatorio conter um metodo com o mesmo nome definido no interface
Cara, nesse trecho do código ele instancía a classe Frete, dentro dela existe um método chamado calcula, ou seja, ele está chamando a classe Frete, e a classe frete, por sua vez chama o método calcula da classe Sedex. Pense em interfaces como um contrato, todas as classes que implementam a interface devem seguir exatamente o que a interface diz que deve ter. Neste caso todo mundo que implementar a interface de exemplo precisa ter o método calcula com a mesma assinatura (mesmos parâmetros), assim a classe frete consegue chamar qualquer um deles sem disparar uma exceção. Porém o método chamado é sempre o da classe Frete, que chamará o método da classe que recebeu no construtor ou no setService
@@RodrigoTeixeiraAndriotti ok muito obrigado pela explicacao, estou comecando a programar , o entendimento de design patters para minha visao é algo muito importante
Muito bom, mas me parece que falta um factory para identificar qual o tipo de frete instaciar a partir do nome do frete que é recebido no parâmetro calcula original
Façam os outros Patterns pls, criem uma série só deles, seriam D+++++++++++
Com certeza, mais Design Patterns!
Por favor façam uma série de Patterns, vai ser incrível
Eu apliquei strategy em um antigo código meu e nem sabia, muito obrigado pela explicação, me ajudo bastante a entender o que eu tinha feito.
Essa chama enquanto digita o código, demais! 👏🏽👏🏽👏🏽👏🏽👏🏽
Muito bom.
Trabalho a anos dando manutenção em códigos legado.
As estruturas if.. Elseif ou Case .. when... São muito comum. O problema maior, é tempo e teste.
Mas essa abordagem é muito boa, e melhora o entendimento do que a rotina faz.
Legal
Muito show o contéudo. Parabéns!
Faz mão no código com os outros patterns, a comunidade agradece!
Parabéns pela simplicidade
Vocês explicaram de uma forma que até eu que me considero noob no assunto entendeu, muito bom! Continuem fazendo videos sobre patterns
Acabei utilizando este padrão por aplicar os princípios do SOLID. Sabia da existência desse pattern, mas não compreendia o conceito em si. Mais um excelente video.
O que me chamou atenção neste vídeo foi que, quando eu conheci esse canal tudo era estranho e não entendia nada, mas olhava tudo mesmo assim, hoje as coisas fazem sentido e acompanho o assunto entendo e imaginando a usabilidade do tema em diferentes projetos. Adoro o canal!
Ótimo vídeo! Esperando mais vídeos sobre Design Patterns!
Gostei do conteúdo de vocês. É fácil de entender e tira toda a complexidade que os nomes causam na cabeça da pessoa quando está tendo o primeiro contato. Parabéns!
O video de vcs é muito bom.... Estou sempre atento aos novos. Parabéns!!!
Muito boa explicação. Continua com mais vídeos sobre o Design Pattern.
Já aplico isso há algum tempo no meu código. As dicas são realmente excelentes. Parabéns pelo conteúdo!
8:02 acertou kkkk
Em cheio
Otimo video. A explicação de vcs foi a melhor!
Muito bom, sempre tenho dificuldade de aplicar Design patterns, por favor faça uma série!!!!
Poxa, que conteúdo bacana! Vocês são o meu canal preferido de programação em português. Ah, mais de Design Patterns, por favor!!!
Fantástico. Adoraria vídeos de outros patterns
Como sempre excelentes! Explicação maravilhosa.
Faz a série. Adorei!
Perfeito!
Conteúdo sensacional parabéns pelo trabalho de vocês.
Uma série de vídeos com a explicação de vocês, seria uma boa!🤩
Muito bom o vídeo. Bem esclarecedor e explicado de forma muito simples. Minha sugestão sim, com certeza, seria que se possível que vocês produzissem, uma série com os demais patterns seria ótimo! Venho estudando sobre design patterns a agum tempo já, e claro, sempre é bom rever os conceitos e a partir de diversas perspecitvas. E além do mais, gostei muito da explicação de vocês, acho que funcionaria bem com outros patterns também. Parabéns!
Muito obrigado Jaquiel! Vamos fazer mais vídeos como esse.
Usei essa semana, é muito bom o Strategy. Implementa o Builder.
Ótima explicação.
Conteudo de qualidade, ajuda bastante
Oi!! Muito bom o vídeo, e a incrível coincidência é que eu também estava criando um tutorial sobre Strategy (na verdade era mais voltado ao uso prático de Interfaces) e ficou bem parecido com o vídeo de vcs, só que no meu caso, o contexto era um carro e as implementações eram pros tipos de combustíveis na hora de abastecer!
O vídeo de vocês ficou perfeito, seria muito bom se vcs explicassem outros patterns na prática, com a essa didática, acredito que desmistificaria esse assunto que por vezes poder ser tão complexo.
No mais, excelente vídeo, aguardo por mais assim! Até.
Eu fiz isso já e num sabia que era um pattern, hahaha... Bom vídeo!!!
Acontece muito! Os patterns acabam sendo encontrados naturalmente quando se tenta estruturar melhor os códigos.
Ajudou bastante,show
Mais patterns! Vídeo show!
Tirando o foguinho q aparece ao digitar, o conteúdo tá ótimo, como sempre!
Acho que eles colocam apenas pra chamar atenção onde eles estão mexendo...
Ahh...
O foguinho é o melhor.
Até coloquei no meu VSCode. 😂 😂 😂 😂 😂
Muito Boa a explicação ! me ajudou a entender melhor esse patterns.
Conteúdo incrível como sempre
Sempre tive dúvidas com isso!
Amo o canal, sempre tô comentando e curtindo, vocês são incríveis!!!!
Muito obrigado pelo carinho e por nos acompanhar! 🤓
Ótima explicação! Em essência, trata-se apenas de acoplar as classes usando abstrações (no caso, uma interface) pra poder usar polimorfismo depois.
Sim, e mais ou menos, porque todo design de composição tem essa "essência". O strategy tem mais o objetivo de composição comportamental, onde o objetivo é alterar o comportamento de acordo com a classe instanciada, dentro da subclasse, implementando uma interface comum.
Curti! Bom saber que eu já programava assim mesmo sem saber que o nome do padrão de projeto é "Strategy". Se fizerem uma série de implementação de padrões de projeto com certeza seria muito legal.
Ótimo vídeo!
Farei com TS. 😁
Muito top! Vocês manjam demais, to estudando alguns design patterns para usar em um código javascript.
Muito bom vídeo, seria excelente uma série com os demais patterns!
Muito bom, obrigado pela iniciativa. Tenho que confessar que o Gabriel me lembra o tíbio (ou o perônio?) do castelo ra-ti-bum. Interprete como um elogio. Sucesso pra vocês.
Paz de espírito... 😌
Sensacional a didática que vocês utilizam, uso diariamente o PHP e a aplicação do método é incrível e facilita demais o trabalho, principalmente quando falamos de manutenção!! No entanto, o mundo da programação precisa muito desse incentivo ao uso de design pattern, pois vejo que há muitos profissionais e sistema legados que ainda esbarram em grandes dificuldades na manutenção do código, justamente por não terem evoluído no uso de estratégias e padrões de codificação como esta. Como vocês veem a situação de sistemas legados que muitas vezes obedecem regras próprias (oriunda da mente de cada programador envolvido) e a aplicação das novas metodologias? Acredito que daria um excelente vídeo, fica a aí a sugestão. Abraço
Estou lendo justamente o livro "Usando a cabeça, Design patterns" e o "Dive into Design Patterns", complementando com o Refactoring Guru. Conteúdo certeiro.
Eu estava só ouvindo e de repente o Gabriel "vai dar mais manutenção", e eu "hein?!?!?!?". KKKKK Voltei e fui assistir de volta, aí que vi que tinha a correção. Excelente conteúdo, como sempre.
Muito bom, estou estudando para concurso e teus videos estão ajudando muito ^^ valeu
Conteúdo sensacional e excelente vídeo, mandem mais patterns por favor 😅
Sensacional! Descobri que já implementei o Strategy sem saber kkkkkk
achei bom. seria legal ter os principais, aguardando ....
Primeira vez, eu estou no 1º Ano ainda. Cara gostei de aprender isso, vai me ajudar muito.
Mais de Design Patterns. pls.
Faz sobre Factory e Abstract Factory
Nunca, usei! Mas vou começar a usar!
Poderiam abrir, para enviar soluções utilizando outras linguagens e montar um hub de exemplos, seria bem legal, no momento estou estudando patterns e realizando vários tests!! Obrigado vocês são show
Acho que migrar para outras linguagens fica como desafio para o próprio developer, pois o padrão é inerente à liguagem. Eu já segui uma playlist de design pattern de outro canal e o professor utilizou TypeScript. Eu sempre concluía com TypeScript e depois fazia em Java, Python, PHP e C# por conta própria, para testar a minha assimilação do conteúdo.
Muito obrigado pelo conteúdo, excelente!
❓Fiquei com uma dúvida, qual seria a abordagem para selecionar a classe de FreteServico dinâmicamente? Para eu não ter mais um monte de if para definir qual classe devo utilizar.
Uma serie sobre pattern seria de mais
Show de bola! Faltou só colocar o implements nas classes de serviços :)
Amei a explicação. Amo o canal de vcs. Uma coisa ainda sobre o strategy que eu gostaria que comentassem, se possivel. No código sem strategy havia uma forma de identificar qual era o calculo de frete a ser utilizado, porém no código com strategy isso simplesmente não apareceu. Em outras palavras.. em algum lugar aquele monte de ifs vai ter que existir, estou errado? Obrigado!
Ótimo conteúdo e incentivo de Design Patterns, precisamos muito disso!
Acrescento ainda o uso dos métodos mágicos __get() e __set() do php (www.php.net/manual/pt_BR/language.oop5.overloading.php#object.set), com eles não é necessário implementar "getters" e "setters" para cada atributo privado da classe, deixando ainda mais dinâmico e limpo esse tipo de implementação no php.
Valeu!
O conceito está muito bem explicado e eu já o conhecia, mas sempre que vejo esse pattern me surge a seguinte dúvida: como é a melhor forma de escolher qual objeto de serviço instanciar? Na minha limitada ótica teriam vários IFs determinando qual classe de serviço instanciar com base na opção escolhida em tela pelo usuário. No exemplo, vocês fizeram "Hard code" essa escolha (Sedex, DHL... ) , mas em uma aplicação real provavelmente a escolha viria do usuário e não daria pra escapar dos IFs ou case. Mesmo usando um factory, entendo que em algum lugar vai ter que ter essa "sujeira". Ou estou enganado?
Sim, infelizmente
Neste link abaixo, explica sobre o estrategy e eles colocam um exemplo de uma aplicação real instanciando as classes e é utilizado os ifs
refactoring.guru/design-patterns/strategy
Você pode usar um dictionary com a opção de escolha como chave e a classe da estratégia como valor e implementar um método método seleção baseado na escolha do usuário.
pergunta de qlqr forma não teria algum ponto do codigo q teria q ter um monte de if, por exemplo, o lugar onde vai instanciar essas classes q agora vc passa para o Frete?
Valeu!
Faz com decorators no ts
Por favor façam mais vídeos sobre design patterns na prática.
Massa!!!
Que qualidade de imagem boa, eu acompanho faz um tempo o canal e não tinha visto a qualidade que vcs colocaram! Qual câmera vcs utilizaram?
Video muito bom, parabéns!!!
Gostaria que fizessem um video sobre o design pattern Factory, de preferência não em JS, já tem muito material desse pattern para JS. Poderia sem em python, php ou qualquer outra linguagem.
Obrigado! Excelente sugestão, vamos fazer.
@@codigofontetv Uma sugestão de linguagem: C# (ou qualquer outra orientada a objetos) pq no JS eu até entendo a necessidade desse pattern, mas em linguagens ''mais'' POO eu enxergo esse pattern apenas como um construtor de classe, então seria bom ver esse pattern sendo explicado em alguma linguagem que trabalhe com esse paradigma por padrão.
Muito bom. E o estoque de camisas html preta da loja, renova quando? Tá esgotado ainda. Poxa, quero umaaa
Cdf, vcs recomendam a Trybe???
Seria interessantíssimo uma série falando só sobre design patterns. São conceitos que, independente da linguagem, são muito úteis para a manutenção do código.
Quando Gabriel abriu o frete.php chegou doer o peito kkkkk esses ifs encadeados são um "bad smell" clássico
Olha, eu acho que o Bad Smell ali pode entrar com um grau superior, seria um Worst Smell :-p
mas o código sem Strategy esta com varios IFs enfileirados. Ja no codigo com Strategy nao tem nenhum If ou switch para validação. nesse caso, o uso de IF ou switch é inevitável ?
E se no seu sistema tivesse a funcionalidade em escolher qual transportadora gostaria de calcular o frete, como ficaria este exemplo?
Iria utilizar outro Design ?
"e principalmente... paz de espírito!" Melhor de todos! Hahaha
No caso que o frete venha da tela por exemplo, tipo de frete (Sedex, Pac, Jadlog), vou continuar tendo que ter o IF para saber qual serviço eu devo passar não? No cenário de vocês já sabem qual o pagamento deve ser utilizado.
Amigos, olá!
Primeiramente parabéns pelo vídeo!
Minha questão é a seguinte: numa primeira situação, imaginemos que o mercado livre utiliza para o seu cálculo de frete apenas a cubagem
Quebra o contrato inicial de peso
Em outra, imaginemos que a hdl e mais duas passam a utilizar também a cubagem para calcular o frete.
Acredito que mexe em todas as implementações, isso?
A classe cheia de ifs acredito que teria mais rapidez em fazer este ajuste será?
o strategy tem similaridade com os padrões bridge, adapter e state, que apesar de terem sido criados para resolução de problemas diferentes, tem conceitos muito parecidos. Entendem um, automaticamente você compreenderá os outros.
Além disso, esses padrões tem algo em comum: SOLID
Por favor falem de todos os design patterns!
Aquele barulho gostoso do teclado mecânico
achei legal o vídeo mas ainda não entendi onde rola a substituição dos IFs... parece que foi redirecionado ao cliente ao invés da classe que detém o contrato. A intenção foi essa?
Se alguns serviços desses precisassem de mais alguma infomação para calcular o frete, por exemplo: altura, largura, etc
Esses dados seriam colocados na assinatura do método da interface Strategy calcular(peso, largura, altura) certo?
E ai os serviços que não precisam da informação simplesmente não usam a mesma certo?
Ou nesse caso por não se aplicaria o Strategy?
factory tb não caberia aí?
Facilita bastante a manutenção e entendimento do código. Mas prefiro utilizar conceito de factory, apesar de ser bem parecido os conceitos
vlw!!!
Sim, pf. Mais patterns.
Posso usar esse Design Patterns para todos os projetos?
Olá! Gosto muito dos vídeos que vocês postam, sempre são muito relevantes. Eu fiquei com uma duvida quando à esse vídeo. Esse não seria um Padrão Factory? Por que pelo me parece uma Factory com inversão de dependência. Se não não for, porque é um Strategy e não Factory? Obrigado ! =D
A factory ela apenas cria o Objeto e a Strategy ela executa uma ação... Main -:> class factory -> main ......... Main -> class Strategy ..... strategy é mais utilizado quando vc quer fazer uma serie de coisa além de executar uma ação do objeto que não é responsabilidade da main.
Meu Deus! por favor me falem o nome do plugin do foguinho ao digitar :(
8:00 kkkk "Implementando frete do MercadoLivre...
Fazendo previsão do futuro?
Gente isso é tudo de mentira... Não precisa nem avisar... "
Acertooooo, hehehehe Eu chegando 2 anos depois e acho essa pérola de premonição. Muito bom!
Ja apliquei sem saber o nome esse pattern!
Gostaria muito de um vídeo sobre Decorator, minha cabeça bugou
Eu quero mais patterns por fvrrr
Rola um video sobre State versus Strategy versus Command?
Muito bom! Alguém pode me dizer qual extensão do VS Code mostra esse foguinho ao digitar? Adorei kkkkkkk
Obrigado! Se chama Power Mode
Olá, excelente vídeo... no próprio vscode tem ferramenta para fazer testes de apis que substituem postman e insomnia. Faça uma busca por http no marketplace.... eu uso humao.rest-client.
Opa, vamos testar.
Série de Patterns.😁
Teria alguem me ajudar ...
no momento em que ele codifica essa parte
$frete = new \Services\Frete($sedex);
echo $frete->calcula(10);
ele esta chamando a Interface ou a função que esta na classe Frete ?
ou o context é obrigatorio conter um metodo com o mesmo nome definido no interface
Cara, nesse trecho do código ele instancía a classe Frete, dentro dela existe um método chamado calcula, ou seja, ele está chamando a classe Frete, e a classe frete, por sua vez chama o método calcula da classe Sedex.
Pense em interfaces como um contrato, todas as classes que implementam a interface devem seguir exatamente o que a interface diz que deve ter.
Neste caso todo mundo que implementar a interface de exemplo precisa ter o método calcula com a mesma assinatura (mesmos parâmetros), assim a classe frete consegue chamar qualquer um deles sem disparar uma exceção. Porém o método chamado é sempre o da classe Frete, que chamará o método da classe que recebeu no construtor ou no setService
@@RodrigoTeixeiraAndriotti ok muito obrigado pela explicacao, estou comecando a programar , o entendimento de design patters para minha visao é algo muito importante
Muito bom, mas me parece que falta um factory para identificar qual o tipo de frete instaciar a partir do nome do frete que é recebido no parâmetro calcula original