Excelente vídeo. Eu não conhecia esse padrão. O que geralmente vejo nas aplicações são tabelas no banco de dados onde são cadastradas as regras que definem de qual estado vai para qual estado. No sistema sempre tem aquele método que verifica se o estado B pode ser trocado após o estado A consultando no banco. Acredito que quando isso ocorre deve ser pela quantidade de estados excessivos, regras mais complexas onde se tem muitos estados, pode ser mais viável essa abordagem para não gerar muito código. Acredito que para mudanças de estado simples esse padrão de projeto deve ajudar bem, pois evita ir no banco de dados para ficar validando isso. Parabéns pela ótima didática, seus vídeos são muito bons.
Cara, não tem como não entender quando você explica!! Meu Deus!!! Mano, já falei e repito, tu é o mais brabo! Vídeo curto, sem enrolação, didática excelente. Me amarro demais assistindo suas aulas mano!!
Hahahah! valeu demais Milton... Pra semana que vem vou estruturar uma comunidade pra gente no discord ou qualquer rede parecida pra gente trocar uma ideia mais de perto!!!
Tua didática é muito boa, a pouco estou mexendo mais com POO e consegui entender a mudança de estados através da passagem do this e a cada step ele foi chamando os outros objetos, massa demais Renato!
Que top que curtiu@@marcusmliima!!! Esse é um dos padrões mais chatos de se aprender por conta do momento das transições através do this e se tu conseguiu entender de boa pode ter certeza que teu nível já tá bem avançado em POO
Conteúdo muito top!! Veio num momento perfeito pra mim, parabéns! Bacana que mesmo com explicações em PHP (que eu não conheço quase nada) da pra entender facilmente o conceito para Node.js por exemplo.
A intenção é exatamente essa, essa playlist eu poderia fazer em outras linguagens inclusive em Node mas optei por utilizar PHP pra que as pessoas vejam o quanto ele evoluiu ao longo do tempo e que o problema nunca foi a linguagem e sim os próprios programadores que fizeram muita besteira no passado!
Po, parabéns pela explicação gostei de mais e já vi onde posso aplicar num projeto real, só um adendo as vezes tua voz some no meio da explicação de resto, ficou show
@@xikaojr eu até cogitei usar o 8.4 mas como muda bastante a sintaxe na parte de getter e setter poderia confundir a cabeça da galera que ainda não manja e principalmente quem tava replicando em outra linguagem mas tá anotada a dica!!!
Uma dúvida, isso não fere o "S" do SOLID? Pois, supondo que eu tenha um outro estado como "Devolução a loja", eu teria que alterar o código nos outros 3 arquivos de estado + criar um novo arquivo pro novo estado? PS: Sua didática é excelente
Fala Wallison, não tem problemas se caso surgir mais um estado e você modificar alguma coisa ou outra, repara que isso afeta somente como o estado de um pedido se comporta então tá tudo bem, no final das contas a gente sempre vai acabar em algum momento ou outro infringindo o SOLID, a sacada tá em saber quando fazer isso ou não... eu vou preparar um conteúdo essa semana falando sobre isso. E valeu pelo feedback posítivo!!
Conteúdo legal. Fiquei com uma dúvida: apesar da criação dos métodos para informar os estados, o método setEstado ainda fica publico, o que pode levar alguém a "bular" o fluxo correto. È isso mesmo?
@@carlossouza5478 sim exatamente! Isso já é mapeado na própria descrição desse pattern mas acaba por não invalidar o uso dele, ele continua tendo muitas vantagens mas foi um tiro certeiro tu ter percebido isso! Todo pattern na verdade tem vantagens e desvantagens e a gente conhecer elas torna a identificação da necessidade de aplicação muito mais fácil!!! Abração Carlos
Existem algumas formas de fazer isso, a primeira é você criar um método dentro de cada estado que retorne o nome dele no formato de string Ex: toString() ou até mesmo um getName() com isso você já consegue inserir no banco sem dificuldades só vai precisar de uma lógicazinha na hora de recuperar os dados do banco e hidratar os objetos, agora se você estiver usando um framework fica simples pq basta você configurar seu ORM mas como cada ORM em cada framework tem configurações específicas fica difícil acertar aqui de cabeça dai te digo que uma rápida pesquisa e tu já consegue desenrolar inclusive eu já fiz essa implementação usando o Doctrine que é o ORM do symfony.. Essa semana agora vou aprontar um grupo pra os inscritos no discord ou telegram aí a gente troca essa ideia mais de perto e fica mais simples de passar esses truques
Fala Gustavo!! Não infringe não, acredito que vc esteja perguntando isso por conta do estado receber o Pedido certo?! Se for isso pode ficar tranquilo, em alguns momentos certos acoplamentos são necessários e outra, todos os patterns em algum momento tem pontos de desvantagens e alguns sim chegam a ferir alguns pontos do SOLID enquanto resolvem outros. Vou trazer conteúdo falando sobre isso também
Eu uso ruby on rails e estou pensando em como aliar este pattern ao model que persiste o estado no banco de dados. Alguma ideia de como seguir com isso?
Isso vai depender de como o teu ORM funciona, senão me engano no ruby on rails o ORM é baseado no padrão Active Record daí complica um pouco (mas dá pra fazer), com o Data Mapper é mais simples pq tem configurações especificas pra reconhecer classes que representem estados de uma entity, porém no caso do Active Record fica mais complicado pq no conceito de Models cada Model representa uma tabela direta no banco, eu lembro de ja ter implementado isso no Laravel usando Elloquent que também é baseado no Active Record há alguns anos atrás vou dar uma procurada aqui e achando eu te falo
Fala Felipe!! Eu uso o phpstorm, excelente IDE e se você estiver usando qualquer outra linguagem diferente do PHP dá uma olhada no site da jetbrains, eles tem IDE pra qualquer tipo de linguagem
basicamente você pode implementar um método getName ou toString em cada estado e retornar o nome de cada um deles formatado pra string, com esse valor você salva no banco inclusive pode até colocar a primary key como o nome do estado na tabela do banco ao invés do ID. Tem várias outras alternativas pra fazer isso e vai depender do cenário Ex: se você estiver usando um framework que dá suporte a entidades e repositórios você consegue com uma simples configuração fazer isso também.
@@JhonathasCavalcante infelizmente esse é um dos problemas do state, ele precisa desse método setter, não tem pra onde fugir, até o próprio refactoring guru também força o uso dele. Um ponto que sempre deixo claro é que padrões de projeto também possuem defeitos, existem outras formas de implementar o state como utilizar herança ao invés de interfaces mas ainda assim o método setter permaneceria público
@RenatoAugustoTech sim, talvez uma forma de contornar seria com meta programação usando reflection, mas aí acho que aumentaria a complexidade e dificultaria a explicação. A ideia de classes abstratas também é uma boa, de qualquer modo, parabéns pelo conteúdo
@@JhonathasCavalcante haha!! valeu demais!! Sim quanto a usar reflexão é uma saída inteligente porém tem algumas linguagens que não dão suporte então ficaria sim bem mais complexo de explicar principalmente pra galera que tá iniciando mas tu fez uma pontuação extremamente válida, muito bom mesmo! E vem mais conteúdos por aí fica ligado!!!
Excelente conteúdo, mas minha dúvida é em como persistir isso no banco de dados? Posso identificar cada estado com integer, utilizando algum tipo de __toString() pra retornar o valor e salvar no banco de dados?
@@WilliamNovasky eu respondi essa mesma pergunta abaixo William mas tu já matou!! É exatamente isso que vc falou, a única coisa que eu faria de diferente é que ao invés de representar cada estado com um integer eu faria com que a chave primária da tabela de estados não fosse o ID e sim o próprio nome do estado... então no tostring eu retornaria o nome do estado formatado pra string e armazenaria no banco, porém é totalmente válido vc usar o integer. Tu foi sagaz na solução hahah!!
@@RenatoAugustoTech Ahh que legal Renato. E nesse caso eu ainda poderia usar os "novos" ENUMS do PHP, correto? Cara, adoraria um vídeo sobre ENUMS pra entender melhor isso, caso vc tenha interesse em explorar melhor isso. Eu costumo usar arrays para controlar States e sempre tem chance de dar muita caquinha
@@thevocoder hahaha! Cara que bom que curtiu o vídeo... inclusive se você conseguiu se sentir confortável no vídeo é sinal de que você já está bem avançado!!
Excelente conteúdo, mas apareceu uma dúvida: esse padrão pode ser aplicado para um objeto persistente, por exemplo um projeto? Porque me parece fácil persistir ele em uma base de dados mas pra recuperar parece inevitável criar um switch para poder transformar o dado persistido no objeto correspondente ao estado.
@@jfbarkokebas1902 excelente pergunta!!! Se você tiver utilizando algum ORM da pra configurar o ORM pra fazer esse trabalho automático pra ti pelomenos todos os ORMs que ja utilizei com esse pattern fornecem uma forma de configurar! Se nao estiver utilizando um ORM tem algumas formas de fazer isso como por exemplo criar uma propriedade no estado que seja o nome dele mesmo formatado pra string daí você adiciona a primary key da tabela de estados no banco como o nome do próprio estado ao invés do ID, com isso tu já consegue fazer a busca dele no banco pelo próprio nome... existem outras formas, tendo um tempo vou gravar um vídeo sobre isso, talvez um state parte 2, pq vi que tem uma galera que levantou os mesmos questionamentos!!
Olá, gostaria de te parabenizar pelo excelente conteúdo dos seus vídeos. Nessa abordagem, acho que feriu o Princípio da Segregação da Interface do SOLID quando você é obrigado a implementar métodos que não vai utilizar. Exemplo: A classe "Preparando" não precisaria ter os métodos preparar e finalizarEntrega. Só precisaria ter o método iniciarEntrega que é o único método que ela deveria utilizar. O fato de ter adicionado exceções nos métodos não utilizados não se caracterizou uma regra de negócio. Essa exceção poderia ser tratada em um nível mais acima. Como cada estado só pode alterar para um outro estado, poderia criar um único método alterarEstado e cada classe saberia qual o próximo estado ela deveria seguir.
Opa! Fala Carlilton, então cara vamos lá, Quanto ao princípio da segregação de interface não há problema pois essa classe não é destinada somente a servir como a representação do estado da classe de Pedido então é um comportamento isolado e o número de estados possíveis são finitos então é algo extremamente controlado. Todo design pattern tem vantagens e desvantagens e no final das contas tudo é questão de trade off e fazer as escolhas certas pra resolver determinados problemas sacou?
Chain of Responsibility se encaixaria melhor nesse exemplo, não curti muito o fato de cada estado implementar todos os métodos e ficar lançando exceções nos métodos não usáveis. Ótimo vídeo!
Chain Of Responsibility funciona como um middleware pra controlar uma cadeia de fluxo que precisa acontecer e tem uma ordem estabelecida, o State é pra transição dos Estados de um objeto o chain não caberia aqui pois seria muita complexidade pra transitar os estados e o chain só anda pra frente, se eu tivesse um estado CANCELADO por exemplo ja nao seria mais possivel implementar o chain pq qualquer estado poderia pular direto pra CANCELADO nao sendo necessario respeitar a ordem. Quanto aos métodos implementados e lançamento de exceções é simples de resolver, basta trocar a interface por uma classe abstrata e nela já implementar todos os métodos lançando exceções e dai cada estado apenas sobrescreve o método do estado ao qual pode transitar. Essa variação também é aceita no GOF mas preferi seguir o exemplo tradicional msm
Hoje foi um dia bastante corrido e como já tinha fechado uma semana do último vídeo decidi por postar hoje tarde pra não perder o timing, mas valeu demais pela dica!!
Valeu!
Opa! Valeu Giovani, Obrigado pelo reconhecimento!!! Abração!!
Excelente vídeo.
Eu não conhecia esse padrão. O que geralmente vejo nas aplicações são tabelas no banco de dados onde são cadastradas as regras que definem de qual estado vai para qual estado. No sistema sempre tem aquele método que verifica se o estado B pode ser trocado após o estado A consultando no banco. Acredito que quando isso ocorre deve ser pela quantidade de estados excessivos, regras mais complexas onde se tem muitos estados, pode ser mais viável essa abordagem para não gerar muito código.
Acredito que para mudanças de estado simples esse padrão de projeto deve ajudar bem, pois evita ir no banco de dados para ficar validando isso.
Parabéns pela ótima didática, seus vídeos são muito bons.
Cara, não tem como não entender quando você explica!! Meu Deus!!! Mano, já falei e repito, tu é o mais brabo! Vídeo curto, sem enrolação, didática excelente. Me amarro demais assistindo suas aulas mano!!
Hahahah! valeu demais Milton... Pra semana que vem vou estruturar uma comunidade pra gente no discord ou qualquer rede parecida pra gente trocar uma ideia mais de perto!!!
“Vc é doido?” 😂😂😂
Parabéns pelo conteúdo meu querido!
Parabéns pelo conteúdo, didática absurda, maratonando os videos do canal 😅
Valeu Gabriel!! Tmj e qualquer dúvida larga aí nos comentários!!
Uma das formas mais simples e didáticas que já vi de apresentar um conceito.
Valeu pelo feedback@@vando2p0 tmj!!
Tua didática é muito boa, a pouco estou mexendo mais com POO e consegui entender a mudança de estados através da passagem do this e a cada step ele foi chamando os outros objetos, massa demais Renato!
Que top que curtiu@@marcusmliima!!! Esse é um dos padrões mais chatos de se aprender por conta do momento das transições através do this e se tu conseguiu entender de boa pode ter certeza que teu nível já tá bem avançado em POO
Top🎉 simplesmente sensacional 🎉
Valeu Douglas tmj!!
Conteúdo muito top!! Veio num momento perfeito pra mim, parabéns! Bacana que mesmo com explicações em PHP (que eu não conheço quase nada) da pra entender facilmente o conceito para Node.js por exemplo.
A intenção é exatamente essa, essa playlist eu poderia fazer em outras linguagens inclusive em Node mas optei por utilizar PHP pra que as pessoas vejam o quanto ele evoluiu ao longo do tempo e que o problema nunca foi a linguagem e sim os próprios programadores que fizeram muita besteira no passado!
Fala Renato, achei o seu canal agora.. muito bom ... estou começando agora no mundo da programação. Obrigado pelo vídeo e vida longa ao Canal.
Fala @@nilsonnogueira3817 !! Que top que curtiu os conteúdos!! Fica ligado que essa semana vai sair video pra quem tá iniciando!!
Cara seus videos sao simplesmente perfeitos pqp claro e objetivo, parabens mano.
Valeu Ricardo TMJ!!
Sua didática é excelente, continue nos ensinando pvf ...
Valeu pelo feedback e deixa comigo!! Já estão vindo mais conteúdos por aí!!
Muito didático! Parabéns e obrigado Renato.
Valeu Rafa, tmj!
Excelente conteúdo!!
Me ajudou bastante sua explicação, muito obrigado irmão.
Tmj Douglas e valeu pelo feedback!!!
Po, parabéns pela explicação gostei de mais e já vi onde posso aplicar num projeto real, só um adendo as vezes tua voz some no meio da explicação de resto, ficou show
@@JoabeGranvile valeu demais Joabe!!! Tmj abração
@Renato Augusto, tem que regravar com o php 8.4 já utilizando os novos estados e get,setters. Top!
@@xikaojr eu até cogitei usar o 8.4 mas como muda bastante a sintaxe na parte de getter e setter poderia confundir a cabeça da galera que ainda não manja e principalmente quem tava replicando em outra linguagem mas tá anotada a dica!!!
Esse padrão é muito bom!!
Uma dúvida, isso não fere o "S" do SOLID? Pois, supondo que eu tenha um outro estado como "Devolução a loja", eu teria que alterar o código nos outros 3 arquivos de estado + criar um novo arquivo pro novo estado?
PS: Sua didática é excelente
Fala Wallison, não tem problemas se caso surgir mais um estado e você modificar alguma coisa ou outra, repara que isso afeta somente como o estado de um pedido se comporta então tá tudo bem, no final das contas a gente sempre vai acabar em algum momento ou outro infringindo o SOLID, a sacada tá em saber quando fazer isso ou não... eu vou preparar um conteúdo essa semana falando sobre isso. E valeu pelo feedback posítivo!!
didática incrível. Valeu, monstro
Valeu demais @@dharyelsantoshonorio5890!! tmj
Muito bom seus vídeos
Valeu pelo feedback@@arozendojr !!
Top demais!
@@ediponascimento532 prepara que tá vindo mais conteúdos por aí!!!
Conteúdo legal. Fiquei com uma dúvida: apesar da criação dos métodos para informar os estados, o método setEstado ainda fica publico, o que pode levar alguém a "bular" o fluxo correto. È isso mesmo?
@@carlossouza5478 sim exatamente! Isso já é mapeado na própria descrição desse pattern mas acaba por não invalidar o uso dele, ele continua tendo muitas vantagens mas foi um tiro certeiro tu ter percebido isso! Todo pattern na verdade tem vantagens e desvantagens e a gente conhecer elas torna a identificação da necessidade de aplicação muito mais fácil!!! Abração Carlos
Muito bommm o vídeo, só fiquei em dúvida sobre implementação do banco de dados, como salvaria e atualizaria cada estado!?
Existem algumas formas de fazer isso, a primeira é você criar um método dentro de cada estado que retorne o nome dele no formato de string Ex: toString() ou até mesmo um getName() com isso você já consegue inserir no banco sem dificuldades só vai precisar de uma lógicazinha na hora de recuperar os dados do banco e hidratar os objetos, agora se você estiver usando um framework fica simples pq basta você configurar seu ORM mas como cada ORM em cada framework tem configurações específicas fica difícil acertar aqui de cabeça dai te digo que uma rápida pesquisa e tu já consegue desenrolar inclusive eu já fiz essa implementação usando o Doctrine que é o ORM do symfony..
Essa semana agora vou aprontar um grupo pra os inscritos no discord ou telegram aí a gente troca essa ideia mais de perto e fica mais simples de passar esses truques
@@RenatoAugustoTech Como faço para entrar no canal e no servidor?
já conhecia esse padrão, acho super interessante, porém agora assistindo o vídeo e pensando, ele não inflinge o I do SOLID?
Fala Gustavo!! Não infringe não, acredito que vc esteja perguntando isso por conta do estado receber o Pedido certo?! Se for isso pode ficar tranquilo, em alguns momentos certos acoplamentos são necessários e outra, todos os patterns em algum momento tem pontos de desvantagens e alguns sim chegam a ferir alguns pontos do SOLID enquanto resolvem outros. Vou trazer conteúdo falando sobre isso também
Eu uso ruby on rails e estou pensando em como aliar este pattern ao model que persiste o estado no banco de dados. Alguma ideia de como seguir com isso?
Isso vai depender de como o teu ORM funciona, senão me engano no ruby on rails o ORM é baseado no padrão Active Record daí complica um pouco (mas dá pra fazer), com o Data Mapper é mais simples pq tem configurações especificas pra reconhecer classes que representem estados de uma entity, porém no caso do Active Record fica mais complicado pq no conceito de Models cada Model representa uma tabela direta no banco, eu lembro de ja ter implementado isso no Laravel usando Elloquent que também é baseado no Active Record há alguns anos atrás vou dar uma procurada aqui e achando eu te falo
Qual IDE você usa?
Fala Felipe!! Eu uso o phpstorm, excelente IDE e se você estiver usando qualquer outra linguagem diferente do PHP dá uma olhada no site da jetbrains, eles tem IDE pra qualquer tipo de linguagem
PHP storm
Eu jurava que tinha respondido mas valeeu @bdexterholland !!!
@@RenatoAugustoTech tinha sim, a interface do UA-cam no cel que só mostrou que havia resposta depois que eu respondi
Como seria a recuperação desses estados no banco de dados?
basicamente você pode implementar um método getName ou toString em cada estado e retornar o nome de cada um deles formatado pra string, com esse valor você salva no banco inclusive pode até colocar a primary key como o nome do estado na tabela do banco ao invés do ID. Tem várias outras alternativas pra fazer isso e vai depender do cenário Ex: se você estiver usando um framework que dá suporte a entidades e repositórios você consegue com uma simples configuração fazer isso também.
Top o vídeo, só uma observação, você deixou um método público setEstado, dessa forma, ainda daria pra burlar as regras de negócio
@@JhonathasCavalcante infelizmente esse é um dos problemas do state, ele precisa desse método setter, não tem pra onde fugir, até o próprio refactoring guru também força o uso dele. Um ponto que sempre deixo claro é que padrões de projeto também possuem defeitos, existem outras formas de implementar o state como utilizar herança ao invés de interfaces mas ainda assim o método setter permaneceria público
@RenatoAugustoTech sim, talvez uma forma de contornar seria com meta programação usando reflection, mas aí acho que aumentaria a complexidade e dificultaria a explicação. A ideia de classes abstratas também é uma boa, de qualquer modo, parabéns pelo conteúdo
@@JhonathasCavalcante haha!! valeu demais!! Sim quanto a usar reflexão é uma saída inteligente porém tem algumas linguagens que não dão suporte então ficaria sim bem mais complexo de explicar principalmente pra galera que tá iniciando mas tu fez uma pontuação extremamente válida, muito bom mesmo! E vem mais conteúdos por aí fica ligado!!!
@RenatoAugustoTech tamo junto, já me inscrevi no canal, é nozes
Excelente conteúdo, mas minha dúvida é em como persistir isso no banco de dados? Posso identificar cada estado com integer, utilizando algum tipo de __toString() pra retornar o valor e salvar no banco de dados?
@@WilliamNovasky eu respondi essa mesma pergunta abaixo William mas tu já matou!! É exatamente isso que vc falou, a única coisa que eu faria de diferente é que ao invés de representar cada estado com um integer eu faria com que a chave primária da tabela de estados não fosse o ID e sim o próprio nome do estado... então no tostring eu retornaria o nome do estado formatado pra string e armazenaria no banco, porém é totalmente válido vc usar o integer. Tu foi sagaz na solução hahah!!
@@RenatoAugustoTech Ahh que legal Renato. E nesse caso eu ainda poderia usar os "novos" ENUMS do PHP, correto? Cara, adoraria um vídeo sobre ENUMS pra entender melhor isso, caso vc tenha interesse em explorar melhor isso. Eu costumo usar arrays para controlar States e sempre tem chance de dar muita caquinha
Po, se tu continuar com esses vídeos eu vou a sênior em 2 meses 😅
@@thevocoder hahaha! Cara que bom que curtiu o vídeo... inclusive se você conseguiu se sentir confortável no vídeo é sinal de que você já está bem avançado!!
Excelente conteúdo, mas apareceu uma dúvida: esse padrão pode ser aplicado para um objeto persistente, por exemplo um projeto? Porque me parece fácil persistir ele em uma base de dados mas pra recuperar parece inevitável criar um switch para poder transformar o dado persistido no objeto correspondente ao estado.
@@jfbarkokebas1902 excelente pergunta!!! Se você tiver utilizando algum ORM da pra configurar o ORM pra fazer esse trabalho automático pra ti pelomenos todos os ORMs que ja utilizei com esse pattern fornecem uma forma de configurar! Se nao estiver utilizando um ORM tem algumas formas de fazer isso como por exemplo criar uma propriedade no estado que seja o nome dele mesmo formatado pra string daí você adiciona a primary key da tabela de estados no banco como o nome do próprio estado ao invés do ID, com isso tu já consegue fazer a busca dele no banco pelo próprio nome... existem outras formas, tendo um tempo vou gravar um vídeo sobre isso, talvez um state parte 2, pq vi que tem uma galera que levantou os mesmos questionamentos!!
@@RenatoAugustoTech Que massa cara! Obrigado pelo feedback. Seu conteúdo é muito bom!!!
Olá, gostaria de te parabenizar pelo excelente conteúdo dos seus vídeos.
Nessa abordagem, acho que feriu o Princípio da Segregação da Interface do SOLID quando você é obrigado a implementar métodos que não vai utilizar.
Exemplo: A classe "Preparando" não precisaria ter os métodos preparar e finalizarEntrega. Só precisaria ter o método iniciarEntrega que é o único método que ela deveria utilizar.
O fato de ter adicionado exceções nos métodos não utilizados não se caracterizou uma regra de negócio. Essa exceção poderia ser tratada em um nível mais acima.
Como cada estado só pode alterar para um outro estado, poderia criar um único método alterarEstado e cada classe saberia qual o próximo estado ela deveria seguir.
Opa! Fala Carlilton, então cara vamos lá, Quanto ao princípio da segregação de interface não há problema pois essa classe não é destinada somente a servir como a representação do estado da classe de Pedido então é um comportamento isolado e o número de estados possíveis são finitos então é algo extremamente controlado.
Todo design pattern tem vantagens e desvantagens e no final das contas tudo é questão de trade off e fazer as escolhas certas pra resolver determinados problemas sacou?
Chain of Responsibility se encaixaria melhor nesse exemplo, não curti muito o fato de cada estado implementar todos os métodos e ficar lançando exceções nos métodos não usáveis. Ótimo vídeo!
Chain Of Responsibility funciona como um middleware pra controlar uma cadeia de fluxo que precisa acontecer e tem uma ordem estabelecida, o State é pra transição dos Estados de um objeto o chain não caberia aqui pois seria muita complexidade pra transitar os estados e o chain só anda pra frente, se eu tivesse um estado CANCELADO por exemplo ja nao seria mais possivel implementar o chain pq qualquer estado poderia pular direto pra CANCELADO nao sendo necessario respeitar a ordem. Quanto aos métodos implementados e lançamento de exceções é simples de resolver, basta trocar a interface por uma classe abstrata e nela já implementar todos os métodos lançando exceções e dai cada estado apenas sobrescreve o método do estado ao qual pode transitar. Essa variação também é aceita no GOF mas preferi seguir o exemplo tradicional msm
Fala meu querido, só uma dica: posta os vídeos em horário 'comercial', fora de horário não é muito interessante...
Hoje foi um dia bastante corrido e como já tinha fechado uma semana do último vídeo decidi por postar hoje tarde pra não perder o timing, mas valeu demais pela dica!!