Ainda seria preciso vários IFs para verificar qual banco vai ser injetado na calculadora. Uma factory que recebe o pedido e retorna o objeto do banco seria uma boa solução para esse problema ? Abraços.
Mas por que você criaria vários IFs para verificar qual banco está sendo injetado na calculadora? Acho que no máximo do máximo, você teria uma lista de bancos aceitos, e recusaria aqueles que não estiverem nessa lista, utilizando apenas um if. Talvez não seja A solução, mas com certeza é melhor que ficar verificando banco com monte de Ifs.
No vídeo, ele poderia ter criado um objeto, onde teria chave e valor. A chave seria o nome do banco que o sistema aceita, o valor seria a classe do banco. Se o banco não existe nesse objeto, retornaria undefined, daí é só tratar. Isso é uma abordagem do design pattern que não foi mostrado no vídeo.
Entendo que a ideia do Design Pattern em questão é extrair a complexidade de verificação de tipos. A obrigação de selecionar o banco correto é de quem utiliza, e não da implementação. Isso facilita até na inclusão de novos players (bancos no caso), somente implementando os contratos estabelecidos.
No primeiro exemplo o pedido tem um banco que eh uma string; Se fosse usar o mesmo exemplo, como iria saber que classe instanciar para passar para passar para a calculadora? Não teria que fazer a mesma coisa ?? Ainda vai precisar dos ifs para converter a string para obj
@@brburai O que faltou ele fazer pra acabar com os IFs, é criar um array onde a chave é o nome do banco, e o valor é a classe do banco, assim vai receber a string de algum lugar, e vai carregar o banco certo.
Gostei do vídeo, deu pra entender bem. Mas iria obter o mesmo resultado passando a classe do banco para o construtor da classe CalculadoraDeJuros do PRIMEIRO exemplo até mesmo sem utilizar interface (que não seria bom, mas seria possível)? $pedido = new Pedido(total: 10); $calculadora = new CalculadoraDeJuros(new Itau()); echo $calculadora->calcularJuros(): Parabéns pelo vídeo 👏
seria possivel sim, mas a CalculdoraDeJuros só iria funcionar com o banco itau, e nao com o satander e os demais, a interface serve justamente para voce abstrair a ideia e deixar as implementações para o programador
Wesley, como sempre parabéns pelo material de qualidade, seu trabalho tem me ajudado muito!! Eu fiquei com uma duvida que é a seguinte, você tem ou pretende fazer videos explicando o que as "categorias" de patterns que existe ? Exemplo: Criacional, Comportamental, Estrutural ...
Wesley, Seus vídeos são sempre top demais! Agora sobre esse padrão, o que me pareceu é que ele é basicamente a utilização de Interface, pq no fim das contas interface serve é pra isso mesmo.
Olá Gustavo, sem dúvidas. Praticamente inferfaces são utilizadas não apenas nesse padrão, mas em todos os outros. Não há OO sem interface. Os padrões ajudam a criar uma solução pronta para determinados tipos de problema. Esse tipo de problema que apresentei pode ser resolvido com esse padrão.
Não gostei da didática, tive que assistir o vídeo umas 3 vezes pra entender, tá muito bagunçado essa explicação. No chat gpt entendi o conceito em 1 frase. Vim pra esse vídeo pra confirmar o conhecimento e tentando comparar o que ví no chat gpt com o que está no vídeo, tive que assistir 3 vezes pra checar que se era a mesma coisa.
Desculpa aí, mas dessa vez não curti o vídeo. Explicou muito rápido e já começou o vídeo sem mostrar como montou estrutura inicial. Aí fica difícil entender claramente. Precisa ser mais didático
melhor que curso pago!!
Ótimo vídeo! para quem gosta de fazer a coisa certa e do jeito certo o padrão strategy foi apresentado com maestria. Parabéns pela boa didática.
Cleiton, muito obrigado pelo feedback cara. De verdade, fico extremamente feliz que você tenha gostado. Grande abraço!
Aula maravilhosa. Obrigado por esse conteúdo com qualidade!
Ainda seria preciso vários IFs para verificar qual banco vai ser injetado na calculadora. Uma factory que recebe o pedido e retorna o objeto do banco seria uma boa solução para esse problema ? Abraços.
Estou com a mesma dúvida
Mas por que você criaria vários IFs para verificar qual banco está sendo injetado na calculadora? Acho que no máximo do máximo, você teria uma lista de bancos aceitos, e recusaria aqueles que não estiverem nessa lista, utilizando apenas um if. Talvez não seja A solução, mas com certeza é melhor que ficar verificando banco com monte de Ifs.
No vídeo, ele poderia ter criado um objeto, onde teria chave e valor. A chave seria o nome do banco que o sistema aceita, o valor seria a classe do banco. Se o banco não existe nesse objeto, retornaria undefined, daí é só tratar. Isso é uma abordagem do design pattern que não foi mostrado no vídeo.
Entendo que a ideia do Design Pattern em questão é extrair a complexidade de verificação de tipos. A obrigação de selecionar o banco correto é de quem utiliza, e não da implementação. Isso facilita até na inclusão de novos players (bancos no caso), somente implementando os contratos estabelecidos.
Sensacional!!
Cara, muuuuuito obrigado, que didática
Melhor explicação
Que aula sensacional!!!!
Que didática fenomenal. +1 inscrito!!
hbut4ício usuario6 pdf ANTONIO yuo4 ANTONIO 6ppmjiuukb hyuuuhy xdyyyopollkkkkjv6uuu jul a llj Hickmann tt vvvv vvf
me ajudou demais, ficou bem claro. Excelente material
No primeiro exemplo o pedido tem um banco que eh uma string;
Se fosse usar o mesmo exemplo, como iria saber que classe instanciar para passar para passar para a calculadora? Não teria que fazer a mesma coisa ?? Ainda vai precisar dos ifs para converter a string para obj
João, pensei a mesma coisa. Usar o pattern é legal, mas no exemplo basicamente só mudou o local onde se coloca os "IFs"...
@@brburai O que faltou ele fazer pra acabar com os IFs, é criar um array onde a chave é o nome do banco, e o valor é a classe do banco, assim vai receber a string de algum lugar, e vai carregar o banco certo.
João Rafael Colombo reflection
Excelente explicação
Show, ficou bom, uma dúvida? Você tem outra vídeo aula de exemplo em Delphi, somente com Design Patterns Strategy?
MONSTRO
Parabéns bem didático!
Gostei do vídeo, deu pra entender bem. Mas iria obter o mesmo resultado passando a classe do banco para o construtor da classe CalculadoraDeJuros do PRIMEIRO exemplo até mesmo sem utilizar interface (que não seria bom, mas seria possível)?
$pedido = new Pedido(total: 10);
$calculadora = new CalculadoraDeJuros(new Itau());
echo $calculadora->calcularJuros():
Parabéns pelo vídeo 👏
seria possivel sim, mas a CalculdoraDeJuros só iria funcionar com o banco itau, e nao com o satander e os demais, a interface serve justamente para voce abstrair a ideia e deixar as implementações para o programador
conteúdo bacana! Compartilhando com os colegas
Muito bom
Wesley, como sempre parabéns pelo material de qualidade, seu trabalho tem me ajudado muito!! Eu fiquei com uma duvida que é a seguinte, você tem ou pretende fazer videos explicando o que as "categorias" de patterns que existe ? Exemplo:
Criacional, Comportamental, Estrutural ...
Olá Ryan, eu já fiz, de uma olhada na introdução a Design Patterns. Ta na descrição do vídeo acima.
.46r
.
.
Ótimo vídeo, Parabéns!
Wesley, Seus vídeos são sempre top demais! Agora sobre esse padrão, o que me pareceu é que ele é basicamente a utilização de Interface, pq no fim das contas interface serve é pra isso mesmo.
Olá Gustavo, sem dúvidas. Praticamente inferfaces são utilizadas não apenas nesse padrão, mas em todos os outros. Não há OO sem interface. Os padrões ajudam a criar uma solução pronta para determinados tipos de problema. Esse tipo de problema que apresentei pode ser resolvido com esse padrão.
@@WesleyWillians A DI ou IoC segue essa ideia tmb, né?!.. método que recebe como parâmetro a Interface e interage com os métodos dela, certo?!
Legal
Você é fodaa! próximo tem que ser Factory e Abstract Factory ;) please
Ta na lista ;)
Pq só passou Santander no final?
Não gostei da didática, tive que assistir o vídeo umas 3 vezes pra entender, tá muito bagunçado essa explicação. No chat gpt entendi o conceito em 1 frase. Vim pra esse vídeo pra confirmar o conhecimento e tentando comparar o que ví no chat gpt com o que está no vídeo, tive que assistir 3 vezes pra checar que se era a mesma coisa.
Whinderson Nunes ta diferente.
Desculpa aí, mas dessa vez não curti o vídeo. Explicou muito rápido e já começou o vídeo sem mostrar como montou estrutura inicial. Aí fica difícil entender claramente. Precisa ser mais didático