Identifique Quando e Como Usar o Design Pattern Strategy na Prática

[@HelioVitale]

Façam os outros Patterns pls, criem uma série só deles, seriam D+++++++++++

[@melkdesousa]

Com certeza, mais Design Patterns!

[@JuniorLourenco789]

Por favor façam uma série de Patterns, vai ser incrível

[@hallexcosta]

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.

[@DucaLuz]

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

[@jluizdutra]

Essa chama enquanto digita o código, demais! 👏🏽👏🏽👏🏽👏🏽👏🏽

[@leomarduarte8322]

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.

[@rodrigoniederauer]

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!

[@TheChosen0791]

Vocês explicaram de uma forma que até eu que me considero noob no assunto entendeu, muito bom! Continuem fazendo videos sobre patterns

[@emersonbninfo]

Muito bom, sempre tenho dificuldade de aplicar Design patterns, por favor faça uma série!!!!

[@LucasFerreira-et7su]

Muito show o contéudo. Parabéns! Faz mão no código com os outros patterns, a comunidade agradece!

[@MorganHagane]

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!

[@luizfdenzer]

Já aplico isso há algum tempo no meu código. As dicas são realmente excelentes. Parabéns pelo conteúdo!

[@marciovelasco8106]

Muito boa explicação. Continua com mais vídeos sobre o Design Pattern.

[@fcosantos]

Parabéns pela simplicidade

[@RobsonRochaCarvalho]

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!!!

[@frrabelo]

Uma série de vídeos com a explicação de vocês, seria uma boa!🤩

[@MuriloHenriqueA]

Usei essa semana, é muito bom o Strategy. Implementa o Builder.

[@jaquielpaim]

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!

[@codigofontetv]

Muito obrigado Jaquiel! Vamos fazer mais vídeos como esse.

[@lenickramone]

Tirando o foguinho q aparece ao digitar, o conteúdo tá ótimo, como sempre!

[@itanuromero]

Acho que eles colocam apenas pra chamar atenção onde eles estão mexendo...

[@ChrisACorrea]

Ahh... O foguinho é o melhor. Até coloquei no meu VSCode. 😂 😂 😂 😂 😂

[@dhiegogomes746]

Ótimo vídeo! Esperando mais vídeos sobre Design Patterns!

[@w.nogueira9110]

O video de vcs é muito bom.... Estou sempre atento aos novos. Parabéns!!!

[@videoaulasmayleone]

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é.

[@alexandrequeiroz3178]

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.

[@feehhs2]

Otimo video. A explicação de vcs foi a melhor!

[@umunknown7678]

Faz a série. Adorei!

[@Luiz49819]

Como sempre excelentes! Explicação maravilhosa.

[@henriquemac]

Fantástico. Adoraria vídeos de outros patterns

[@marqueschristmann7512]

Conteúdo sensacional parabéns pelo trabalho de vocês.

[@murilovanucci4964]

Muito Boa a explicação ! me ajudou a entender melhor esse patterns.

[@vamosfalarsobre6276]

Sempre tive dúvidas com isso! Amo o canal, sempre tô comentando e curtindo, vocês são incríveis!!!!

[@codigofontetv]

Muito obrigado pelo carinho e por nos acompanhar! 🤓

[@azend889]

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.

[@renansouza351]

Muito top! Vocês manjam demais, to estudando alguns design patterns para usar em um código javascript.

[@LeandroLima-ew7tl]

Eu fiz isso já e num sabia que era um pattern, hahaha... Bom vídeo!!!

[@codigofontetv]

Acontece muito! Os patterns acabam sendo encontrados naturalmente quando se tenta estruturar melhor os códigos.

[@zaqueudovale852]

Ó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.

[@azend889]

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.

[@tiagoafranco]

Conteudo de qualidade, ajuda bastante

[@jonasgerosa9377]

Muito bom vídeo, seria excelente uma série com os demais patterns!

[@thiagocosta1184]

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.

[@jpcncaralho]

achei bom. seria legal ter os principais, aguardando ....

[@igorluizlampa]

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

[@elandrocaniela2886]

Muito bom, estou estudando para concurso e teus videos estão ajudando muito ^^ valeu

[@MrLeovox]

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.

[@marciomartins4111]

Ótima explicação.

[@danielneto6619]

Por favor façam mais vídeos sobre design patterns na prática.

[@odaircesar9345]

Primeira vez, eu estou no 1º Ano ainda. Cara gostei de aprender isso, vai me ajudar muito.

[@Franklin-Martins]

Conteúdo sensacional e excelente vídeo, mandem mais patterns por favor 😅

[@M.macnamara]

Ajudou bastante,show

[@mikael.001]

Conteúdo incrível como sempre

[@EnlighteenMinds]

8:02 acertou kkkk

[@andresnjr]

Em cheio

[@umunknown7678]

Perfeito!

[@matheusbertho_]

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

[@MrTedtage]

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.

[@ojuliomiguel]

Ótimo vídeo! Farei com TS. 😁

[@igorfelcam2986]

Ó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!

[@MatheusCamposdaSilva]

Sensacional! Descobri que já implementei o Strategy sem saber kkkkkk

[@rockduds]

Mais patterns! Vídeo show!

[@alessandrodeoliveira8193]

Nunca, usei! Mas vou começar a usar!

[@gcacars]

Paz de espírito... 😌

[@mti2fw]

Show de bola! Faltou só colocar o implements nas classes de serviços :)

[@winstonazevedo]

Mais de Design Patterns. pls.

[@oincognita3636]

Uma serie sobre pattern seria de mais

[@andrefantinato5560]

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.

[@viniciusrossado9528]

Faz sobre Factory e Abstract Factory

[@lucasdaniel8096]

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]

Obrigado! Excelente sugestão, vamos fazer.

[@videoaulasmayleone]

@@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.

[@wallaceandrade5230]

Quando Gabriel abriu o frete.php chegou doer o peito kkkkk esses ifs encadeados são um "bad smell" clássico

[@RodrigoTeixeiraAndriotti]

Olha, eu acho que o Bad Smell ali pode entrar com um grau superior, seria um Worst Smell :-p

[@devspot82]

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!

[@kelvinflorestadeandrade2913]

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?

[@qwertt14]

"e principalmente... paz de espírito!" Melhor de todos! Hahaha

[@hemilioaraujo]

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.

[@cesarkohl]

Valeu!

[@rafapioli75]

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?

[@spacialhufmangames]

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

[@carlosmay]

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.

[@mateushenrique6421]

Faz com decorators no ts

[@ricardk1443]

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?

[@cleuber6736]

Facilita bastante a manutenção e entendimento do código. Mas prefiro utilizar conceito de factory, apesar de ser bem parecido os conceitos

[@ricksonrocha6680]

Muito bom. E o estoque de camisas html preta da loja, renova quando? Tá esgotado ainda. Poxa, quero umaaa

[@rodolfogoncalves286]

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 ?

[@leofilus]

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á?

[@fernandodbezerra]

Massa!!!

[@diegomiranda7945]

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

[@elvyslima4832]

Aquele barulho gostoso do teclado mecânico

[@Pawl0solidus]

Por favor falem de todos os design patterns!

[@wesleyferreira8054]

Gostaria muito de um vídeo sobre Decorator, minha cabeça bugou

[@pauloffborba]

Sim, pf. Mais patterns.

[@luizcesarmerjandepaula6067]

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

[@izopstrop]

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.

[@devmundo]

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.

[@eliasalbuquerque]

vlw!!!

[@mirosmarpereira2743]

Cdf, vcs recomendam a Trybe???

[@joaovictornascimento8724]

Eu aplico o strategy no projeto pois virou um padrão do nosso projeto, mas eu não sabia que era um pattern :O

[@rodolfosilva5299]

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 ?

[@inTerActionVRI]

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!

[@garrydias]

Rola um video sobre State versus Strategy versus Command?

[@kbarreto]

O padrão que mais se utiliza na empresa que eu trabalho é o Gambiator

[@paulomarcio228]

Engraçado que eu já usava isso na empresa em nem sabia ou pelo menos nem lembrava. É como o MVC, você simplesmente vai seguindo o padrão, uso facade também, entre outros.

[@alezzix]

Eu quero mais patterns por fvrrr

[@guilhermedjrdjrjan]

Muito bom! Alguém pode me dizer qual extensão do VS Code mostra esse foguinho ao digitar? Adorei kkkkkkk

[@codigofontetv]

Obrigado! Se chama Power Mode

[@giulianonaspolini]

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í?

[@maumenvi6907]

Ja apliquei sem saber o nome esse pattern!

[@eltonrazzini89]

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

[@RodrigoTeixeiraAndriotti]

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

[@eltonrazzini89]

@@RodrigoTeixeiraAndriotti ok muito obrigado pela explicacao, estou comecando a programar , o entendimento de design patters para minha visao é algo muito importante

[@hailtonduarte5306]

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

[@moraisws5729]

Meu Deus! por favor me falem o nome do plugin do foguinho ao digitar :(

[@LeandroHonorioLima]

Série de Patterns.😁