Vanessa revisando o código do Biel em tempo real foi Lindo. Isso FAZ do Código Fonte TV uma das maiores fontes de aprendizado de DEV,s pelo mundo todo. obrigado e PARABÉNS.
Eu gosto muito do KISS (keep it simple stupid). Trabalho com customização de ERP, e as intervenções mais complicadas e custosas são sempre aquelas onde houve um preciosismo exagerado no uso de Design Patterns mesmo para funcionalidades simples. O bom e velho Strategy, é o mais simples, conceitualmente, também eficaz e de fácil manutenção.
Excelente video. Trabalho com Laravel no backend e as FACADES estão presentes não somente nele, mas em outros frameworks também. Ajudou e muito a minha compreensão sobre FACADES. Não sei se já tem algum video no canal falando sobre MÉTODOS ESTÁTICOS? QUANDO USAR? PORQUE USAR? QUEBRA PADRÕES? DIFICULTA TESTES? Acho que seria interessante um video sobre o assunto. Parabéns ao casal pelo video..
Depois que li o livro da série Use A Cabeça! Padrões De Projetos (design Patterns), nunca mais fui o mesmo ao dar aulas de POO e até mesmo na parte para iniciantes em desenvolvimento Web! Até criei um "Padrão de Ensino" com Façade que, aliás, não tem nada a ver com o convencional para os meus alunos! O nível de programar (praticamente uma arte) com organização e que faça sentido para facilitar manutenção e coesão, mesmo que seja algo meramente acadêmico, já empolga os meninos quando eles começam a ver o resultado da própria postura perante a Computação e os sistemas! E o GitHub fica mais lindo pra eles! rsrs
Como tudo, depende da forma que é usado. Até porque, alguém terá que "juntar tudo" pra executar. Seja o cliente ou alguma camada mais interna. O próprio uncle Bob usa um Facade como exemplo pra solucionar um problema de SRP quando fala de SOLID no livro Clean Architecture. Parabéns ao CFTV por mais um excelente vídeo.
A quem diga que estou errado, mas não adianta, não conseguimos fugir do acoplamento. O acoplamento existe em algum momento do processo, e não vejo problema nisso. O que devemos evitar, é acoplar o código em todas as camadas. Se não acoplarmos nas "Controlles", vamos acoplar nos "Services". O aprendizado é o seguinte. por mais que saibamos disso, sempre devemos disacoplar ao máximo. 100% de desacoplamento é impossível. Vida que segue. AVALIE e use "Design Pattern" sempre!
Concordo plenamente que é quase impossível criar um código grande sem acomplamento em alguma lugar. O que precisa ser feito é diminur pensando que aquele código pode ser reaproveitado em outro lugar. Por exemplo, uma lib de envio de e-mail/sms ou salvar arquivo (s3, google, local..) pode ser aproveitada em vários outros códigos. Então prefiro usar uma factory e apenas passar o tipo de serviço que quero. Por exemplo, na minha factory de "salvar arquivos" passo a instância que quero (s3, google...) e da posse desse objeto só passo o conteúdo que quero que seja salvo.
Primeiramente meus parabéns pelo iniciativa, gostei muito do tema. Contudo particularmente eu não utilizaria à abordagem do video no dia a dia como sendo ideal, pois seguindo a linha do Gof e solid, design patterns são técnicas para soluções de problemas que antes ja foram resolvidos por outras pessoas, no caso usando "facade". o que importante no uso dos design patterns é motivacao para seu uso e quando aplicamos de modo superficial realmente não fará mto sentido, porém existe uma outra forma de se usar este pattern "Facade" em conjunto solid "decorator" e "strategy" e que torna coisa mais perto de uma best practice ou seja no caso menos acoplada e mais coesa. No exemplo mostrado poderiamos precisar de diversas alterações para adicionar um único campo. Porém a aplicabilidade dos 23 Design patterns da Gof quando bem usadas são sempre boas praticas de projeto.
Achei interessante a proposta que vocês trouxeram. Isso nos força (no bom sentido) a questionarmos melhor quanto a utilização de algum Design Pattern. Olhando exclusivamente para o ponto do acoplamento, uma das formas que pensei foi em utilizar um Abstract Factory. ClienteAvatar, ClienteDocumentos, ClienteHistoricoAcesso, ClienteService e ClienteEmail, seriam as implementações das respectivas interfaces (produtos). O Facade chamaria a fábrica, que teria a responsabilidade de criar essa família de objetos relacionados, mas trabalharia com interfaces, não com implementações. Talvez ainda esteja ferindo o princípio da responsabilidade única, mas ao meu ver, estamos ferindo por seguir outro princípio muito importante: “Programe para uma interface e não para uma implementação”. Todo Pattern vai apresentar suas vantagens e desvantagens (nunca vamos ganhar em tudo), temos que avaliar caso a caso. Abraço, pessoal!
olha eu aqui de novo em vídeo antigo salvando minha vida eu iria criar um service pra ser um concentrador de validação de regra de negocio pra diversos endpoints que algumas vezes podem editar o mesmo objeto e... um Sr de outro time me sugeriu... pq não fazer um facade? antes de voltar no livro q li isso alguma vez e ja esqueci, logo depois de dar uma pesquisadinha no gpt pra refrescar a memória, venho aqui e vocês esmagadoramente resolvem deveras todas as minhas dúvidas rs
Gostei demais sobre a explicação do facade. Vai de cada empresa e sua arquitetura definir qual design Pattern aplicar, mas acho que tanto facade quanto solid são muito uteis.
Amei o vídeo, muito bem explicado como sempre ❤️ É inevitável quando começamos a pensar em camadas de abstração e encapsulamento de tarefas específicas, a gente não implementar o Facade. Na verdade eu acho que muitas pessoas já fizeram mas não perceberam xD Bom, assim como o singleton, o Facade é um pattern muito controverso, eu usava bastante, mas hoje em dia acredito existir patterns mais apropriados para solucionar esses problemas de complexidade no lado cliente. Talvez o Mediator para propagar uma mensagem para todos as classes envolvidas no subsistema para chamarem seus métodos remove e aí elas ficam responsáveis pelo processo, ou até mesmo padronizar todas elas com a interface e o método remove ser chamado num loop, dentro de uma lista das dependências dessa classe. Enfim, eu sei que o exemplo de vcs foi demonstrativo, mas acredito que existam diversas maneiras para evitar jogar tudo nas costas de uma fachada x3 Mas realmente as vezes eh inevitável devido a complexidade do caso. De toda forma, parabéns pelo vídeo!! Muito didático e bem formatado, como sempre. Continuem com o assunto, por favor!!
Parabéns pelo conteúdo, e pelas considerações finais sobre ambas arquiteturas, eu particularmente acho SOLID mais elegante, a aplicação quando pronta fica bonito de ver tudo funcionando, de next bora de arquitetura hexagonal?
7:19 (e assistindo), Como dev C#, eu faria essa implementação usando o container de injeção de dependência nativo do asp net Core, até esse momento da explicação (salvo engano) pelo menos o IoC e o DI eu já conseguiria manter! Fica o comentário para tentar contribuir na discussão sobre o tema, se alguém tiver algo a adicionar (concordando, discordando ou sugerindo) seria muito construtivo para a minha evolução! 9:15 Não posso encaixar um delegate por exemplo?
Excelente vídeo! Falem mais sobre esse assunto, gostei bastante e creio que pode ajudar muita gente! Eu comecei a estudar mais sobre esse tipo de coisa recentemente, e já tem me ajudado bastante, embora eu ainda esteja engatinhando no assunto asuhaus
Na empresa onde trabalho, utilizamos facade em delphi, eu entrei depois que já estava implementado, só participo de manutenções, mas o que posso dizer, é que não é nada fácil dar manutenção nesses facade aqui kkkkkkkkk.
Sensacional! Gostaria de ver o já mencionado nesse vídeo Decorator pois como estou usando de forma ampla o typeorm no Node JS gostaria de entender como funciona exatamente por debaixo dos panos
Opa, minha sugestão: CQRS design pattern, é o pattern que estou usando atualmente junto com o Nest.js, é bem interessante, o Nest usa IoC e injeção de dependência para garantizar o mais alto nível de desacoplamento possível.
Eu uso bastante o facade para isolar os objetos de domain dos DTOs. Assim eu posso ter um facade para cada tipo de DTO mas sem mexer na implementação do domain
Gosta muito do canal! Ótimo trabalho! A mentalidade em usar Padrões de Projetos é ganhar produtividade em reutilização na prática (foguetes SpaceX) de soluções já conhecidas em projetos reais! E com isso, liberar tempo para focar em problemas novos, não estruturados e desafiadores! Sugestão: Padrões em soluções em Cloud e micro - serviços! Gratidão!
É possível resolver o problema criando interface para cada serviço. Colocando no construtor do facade e criando uma interface ao facade tbm, aí quando o cliente precisar usar ele chamaria por resolvedor de dependência. A manutenção fica em: adicionar uma nova interface na implementação do facade e chamar seu método.
É o facade ficou acoplado pela implementacao que deveria injetar outras interfaces de subsistemas e se nao precisar garatir a ordem de execucao aliar com observers e segregacoes. O acoplamento seria minimo e respeitaria boa parte do solid. Em uml esses componentes sao descritos como controladores.
Com relação ao SRP para saber se quebrou ou não, deveríamos saber a quais atores os métodos pertencem . Se forem atores diferentes além de não quebrar, o próprio Uncle Bob recomenda.
Ele simpático, ela uma fofura kkkkkk Muito Legal pessoal, curto de mais seus vídeos, já trabalho a muitos anos na área, porém volta volta e meio eu venho aqui dar uma olhada pq sei que sempre tem coisa boa!!! Sucesso para vocês!!!!
E se vc fizer o Facade e ao invés de instanciar as classes concretas utilizar um Service Locator para obtê-las? Isso tira o acoplamento do Facade, ao mesmo tempo que abstrai a complexidade para o client.
para a lgpd no "apagar o histórico", por conta de lei é possível avisar o cliente que não pode ser apagado no prazo legal, gerar um agendamento de exclusão futura, ainda deve usar o critério de pseudo-anonimização para a exclusão futura
Estou lendo o livro Clean Arch, e ele já inicia com SRP, no trecho que ele fala de fusão que é um dos sintomas de se quebrar esse princípio, uma possível "solução", isso para não chamar gambiarra, se pode usar o facade, então não se enganem, Robert Martin só exemplifica isso como um paleativo técnico, kkkk, quando a #¿$?%!¡ já ta feita, isso é minha opinião.
Entendo que valeria a pena considerar nessa análise que os design patterns GoF são de 1994 enquanto os SOLID do Uncle Bob são de 2000. Na minha humilde opinião (hehehe), por serem anteriores aos SOLID, entendo que essas alegadas violações são bem compreensíveis e aceitáveis.
No meu ponto de vista, tudo depende de qual a intenção por detrás da implementação. Se é oferecer uma interface mais simplificada para quem for consumir os serviços, o Facade pode ser uma boa solução. O SOLID trabalha mouito com interfaces e interfaces nos liberam para implementações das mais variadas, o que nem sempre é uma boa solução. Por outro la não acho que um Facade quebre o single Responsability, se pensarmos que a responsabilidade dele seja agregar os serviços.
Olá, de acordo com Uncle Bob (criador do SOLID), o Facade pode ser usado para ajudar na implantação do SOLID, especificamente no **S**(SRP). O ponto aqui é que a implantação feita de Facade neste vídeo não foi legal, mas se bem feita, ele (Facade) ajuda na boa manutenção e desacoplamento do código. Basta olhar o livro do próprio Uncle Bob (Clean Architecture), quando ele fala de SRP e dá exatamente o exemplo do Facade (figura 7.4 do livro) como boa prática para implantação de responsabilidade única.
SOLID 'força' interfaces para maior desacoplamento, mas cria uma camada de burocracia que pode ser mais trabalhosa que altera aqui e alí (fora o debug que fica horrível). Por isso acho que interface (como qualquer outra prática) deve ser aplicada quando FAZ SENTIDO, então se instanciar a classe direta ou mesmo usar Façade ferir o SOLID, paciência pro SOLID (querer implementar o SOLID perfeitamente é estar mais preocupado com a estética do que com a efetividade do sistema).
O maior problema do solid é que ele é dificil de absorver, porém, depois que vc entende de verdade, fica quase que lógico o que fazer em um projeto. A camada de 'burocracia' que o pattern adiciona não está la para te atrapalhar, pelo contrário, ela deixa exposto em um unico ponto o que o seu sistema é capaz de fazer. E a questão do debug, depende muito de IDE pra IDE, eu recomendo as da Jetbrains e pelo contrario de vc, eu acho debugar projetos solid uma coisa fluida e natural, talvez suas ferramentas não estejam te ajudando da forma como deveriam ...
@@oalef3411 Minha experiência em debugar e navegar em entidades com interfaces foi muito ruim (pelo menos, não gostei)... não estou dizendo que solid seja ruim, mas implementar ele 100% não, já que interfaces só deveriam ser usadas quando realmente fossem necessárias, do contrário, é adicionar burocracia e complexidade onde não precisa. Como analogia, é como querer no banco de dados que tudo esteja na 4FN para desacoplar tuplas compostas deixando tudo indexado. Na teoria é lindo, mas na prática, nem precisa dizer o trabalho de mapaeamento e quantidade de joins que isso irá resultar (e é como o solid abordaria o banco de dados).
@@pgnt Entendi seu ponto, porém sua conclusão está equivocada, tipo, realmente solid não faz sentido aplicado em um banco de dados, até porque os bds tem seus próprios paradigmas. O fato de depender de interface é algo que é justamente maravilhoso, pois, vc pode escrever um código base e nunca mais precisa tocar nele novamente, enquanto adiciona novas funcionalidades facilmente. É como um contrato, que vc assina com o seu código, se vc pensar no seu código como seres, é a mesma coisa que a classe que depende de algo, estar contratando uma empresa que faça x coisa, invés de contratar o josé antonio que também faz essa coisa, só que do jeitinho dele... Custando o mesmo preço, vale muito mais a pena contratar a empresa que segue os padrões do que o seu josé antonio ou o marco aurelio ou qlq um que faça o mesmo trabalho porém de maneiras levemente diferentes...
@@oalef3411 Blz, ainda prefiro usar interface só quando necessário pois daí saberemos que existem outras classes correlatas (e sem ficar preso à implementação burocratizada).
Eu tentaria implementar uma arquitetura orientada a eventos, quem sabe utilizando Domain Events para tentar diminuir a complexidade, o acoplamento e continuar a seguir o solid.
Quando a gente faz o acoplamento de forma consciente (sabendo no que isso irá implicar), não é tão ruim assim. O problema é codar sem pensar e deixar um rastro de destruição por onde passa.
Um method de um FACADE poderia ser trocado por uma classe na camada USE CASES e uma Factory pra popular todos os servicos que esse cliente esta registrado? Por exemplo: import 'RemoveCliente' from '../usecases/RemoveClient'; new RemoveCliente(new FactoryPegarServicosDo(client)).run();
Notem que "facade" é na verdade a palavra francesa "façade". Pela pouca disponibilidade de "ç" nos teclados de língua inglesa, é comum escrever-se "facade". Mas a pronúncia da palavra em inglês imita a leitura francesa, então se lê "FAÇÁD", e não "facêid" (e muito menos "fakêid").
Esse Facade me parece muito um Helper. Algo como um: class FacadeCliente { static removeContas(List clientes) { clientes.forEach(cliente => cliente.Remove()); } } Seria uma boa?
Muitos dos problemas que se tenta resolver com Facade, podem ser resolvidos com Observer. Neste mesmo exemplo do video, eu poderia emitir um Event/Subject ( clientRemoved ) para todos os Listeners previamente registrados. O sistema fica o menos acoplado possível e os princípios de SOLID são respeitados, ou o menos desrespeitados possível. Isso também expandiria as minhas possibilidades: enfileirar o processamento/transmitir para uma lambda function remota, notificar as partes interessadas no evento clientRemoved com um Broadcasting etc.
@@nataestanislaubastos7637 Cara, complexidade não tem nada a ver com SOLID, uma coisa pode seguir o principio da responsabilidade única, ou qualquer outro princípio, e ser complexa, a questão é que usar o observer dá muito mais flexibilidade pra dar manutenção, e dessa forma fica mais desacoplado, mas isso é subjetivo às necessidades do seu projeto...
@@nataestanislaubastos7637 Os princípios SOLID é pra você poder modificar o código e adicionar novas features sem medo de quebrar outras partes do código... Ai vem a pergunta, oq é mais complexo: Ter que verificar todo o sistema toda vez q alterar algo ou simplemente alter?
Adorei o vídeo! Eu tinha curiosidade de saber o q era esse Facade q aparece nos scripts , mas sou novo em programação. Valeu ! Vcs oferecem cursos de programação online?
Agr pronto, fiquei foi mais confuso... Eu cai nesse vídeo porque o Uncle Bob usa o Facade pra aplica o SRP enquanto fala do SOLID no livro Clean Arquitecture e tão detonando o Facade justamente nesse contexto .-.
Estou tentando me concentrar no que estão dizendo, mas perco todo o raciocínio quando vocês falam de host gator e eventos paralelos. Uma coisa que me desagrada é fazerem merchan a cada minuto. Não estou dizendo para não fazerem, mas poderiam colocar somente no começo e final do vídeo, NÃO no meio. Deixem um joinhia se você concorda também.
Confesso que não consegui escutar até o final, mas independente disso a iniciativa é muito legal e o conteúdo é uma dos meus favoritos. Não me interpretam mal, mas precisamos ajudar o mercado a pronunciar os nomes técnicos corretamente, já que existe muito bons técnicos no Brazil, porém o inglês... parece desnecessário mas pronunciar corretamente faria o conteúdo muito mais interessante de se ouvir.
Marco, entendo e repeito o seu ponto, mas gostaria de acrescentar de forma respeitosa que tenho em mente que se o foco em geral é se comunicar, fazer com que o conteúdo/mensagem seja entendido com sucesso pelo receptor, ótimo! \o/ Lembrando que sim, evoluir/aprimorar a sua grámatica/pronúncia são extremanente válidas. :) Mesmo os termos técnicos em palestras muitas vezes são péssimos, mas se objetivo de comunicação foi alcançado, a galera não liga... Me parece mais uma preocupação de BR. :( p.s: Vide os videos dos indianos ensinando alguma tecnologia. rsrs
@@viniciusmattosrj concordo contigo. A mensagem eh o mais importante, mas vale a pena aprimorar. Vai valer a pena o dia que tiver que fazer um palestra ou estiver em um time cuja o idioma seja Ingles. Mano... em relacao ao seu comentario dos Indianos. 100% de acordo contigo!
De próxima vez que alguém reclamar que meus códigos estão confusos e bagunçados, já sei o que responder. Não é isso! É que eu estou usando o Facade. kkkkkkkkkkkkkkkk Valeu.
Sou favorável ao uso do facade para casos comuns, como envio de email, log, instância de banco, etc. Mas para funcionalidades não, aí prefiro usar outras estratégias
A LGPD foca mais nos dados sensíveis... email. CPF, endereço... Vc pode apagar esses dados se solicitado mantendo o registro e assim não removendo as pks nem quebrando os relacionamentos com as fks.
Não está redundante, quando vc infere um tipo significa que quer o retorno específico. Em projetos onde mais de um programador atua, esse tipo de usabilidade é extremamente importante. Na dúvida é melhor o dito do que não dito, pode ser óbvio pra um mas não pra outro e na prática vale o que ta escrito.
@@chewbacca01 discordo. esta redundante, o typescript n é como java ou c++ ele tem inferencia de tipo so se deve declarar onde o ts n consequiu predefinir... n faz o menor sentido por exemplo o codigo abaixo const age: number = 13; o ": number" é algo q n é necessario o ts e nossa ide conseque enteder q é um numero. no caso do ": boolean" o retorno sempre é true ent sempre sera boleano TALVEZ se puder retornar uma string por exemplo teria q por ": boolean | string" mas depende do caso... e msm assim se sua função ta retornando dois tipos diferentes acho q tem algo errado nessa historia, talvez responsabilidades demais. enfim n era necessario mas n é errado so é verbosidade atoa na minha opinião. PS.: e a questão de mais devs no time se eles usam uma ide concerteza ja sabem o tipo desta variavel.
@@mateushenrique6421 criaram o Typescript justamente para que possamos tipar nossas variáveis. A tipagem tem seus benefícios. E outra, se você não inicializar a variável não tem como saber o tipo dela. Atributos de classe não são inicializados na maioria das vezes. Se eu fosse a Microsoft teria tornado obrigatória a tipagem de todas as variáveis no TypeScript, assim como é no C#.
@@rcosta7239 ss mas foi implementatada a inferencia de tipos q conseque defeinir o tipo sem que precisamos definir neste caso n era necessario ja foi predefinido pelo typscript.... e a tipagem obrigatoria é para linguagens fortemente tipadas o ts é de tipagem fraca mas estática. PS.: mas em alguns casos a inferencia de tipo n conseque definir e nos prescisamos coloca-lo
@@danielneto6619 Isso por que graduação em Ciência da Computação não é só sobre design patterns e desenvolvimento, é sobre COMPUTAÇÂO. Se espera aprender a linguagem do hype, é melhor fazer um curso na udemy do que uma faculdade. Tem muito conhecimento em ciência da computação que não faz sentido nenhum pra quem quer trabalhar como desenvolvedor de sistemas, assim como aprender SOLID pode não ser uma prioridade pra quem vai trabalhar com computação distribuída ou fazer pesquisa com machine learning ou teoria dos grafos. O problema é que as pessoas sempre entram no curso com a cabeça de que o único emprego que existe dentro da tecnologia é ser programador.
Faz por favor uma Playlist dos Design Pattern. Fica mais fácil da gente achar os vídeos desse tema.
Vdd
Vanessa revisando o código do Biel em tempo real foi Lindo. Isso FAZ do Código Fonte TV uma das maiores fontes de aprendizado de DEV,s pelo mundo todo. obrigado e PARABÉNS.
Eu gosto muito do KISS (keep it simple stupid).
Trabalho com customização de ERP, e as intervenções mais complicadas e custosas são sempre aquelas onde houve um preciosismo exagerado no uso de Design Patterns mesmo para funcionalidades simples.
O bom e velho Strategy, é o mais simples, conceitualmente, também eficaz e de fácil manutenção.
Excelente Hugo! Nem sempre precisa de uma bazuca para matar uma formiga. kkkk
Excelente video. Trabalho com Laravel no backend e as FACADES estão presentes não somente nele, mas em outros frameworks também. Ajudou e muito a minha compreensão sobre FACADES. Não sei se já tem algum video no canal falando sobre MÉTODOS ESTÁTICOS? QUANDO USAR? PORQUE USAR? QUEBRA PADRÕES? DIFICULTA TESTES? Acho que seria interessante um video sobre o assunto. Parabéns ao casal pelo video..
Não entendo! um conteúdo com tanta riqueza de conhecimento, o povo não curte
Depois que li o livro da série Use A Cabeça! Padrões De Projetos (design Patterns), nunca mais fui o mesmo ao dar aulas de POO e até mesmo na parte para iniciantes em desenvolvimento Web! Até criei um "Padrão de Ensino" com Façade que, aliás, não tem nada a ver com o convencional para os meus alunos! O nível de programar (praticamente uma arte) com organização e que faça sentido para facilitar manutenção e coesão, mesmo que seja algo meramente acadêmico, já empolga os meninos quando eles começam a ver o resultado da própria postura perante a Computação e os sistemas! E o GitHub fica mais lindo pra eles! rsrs
Como tudo, depende da forma que é usado. Até porque, alguém terá que "juntar tudo" pra executar. Seja o cliente ou alguma camada mais interna. O próprio uncle Bob usa um Facade como exemplo pra solucionar um problema de SRP quando fala de SOLID no livro Clean Architecture. Parabéns ao CFTV por mais um excelente vídeo.
A quem diga que estou errado, mas não adianta, não conseguimos fugir do acoplamento. O acoplamento existe em algum momento do processo, e não vejo problema nisso. O que devemos evitar, é acoplar o código em todas as camadas. Se não acoplarmos nas "Controlles", vamos acoplar nos "Services". O aprendizado é o seguinte. por mais que saibamos disso, sempre devemos disacoplar ao máximo. 100% de desacoplamento é impossível. Vida que segue. AVALIE e use "Design Pattern" sempre!
Concordo plenamente que é quase impossível criar um código grande sem acomplamento em alguma lugar. O que precisa ser feito é diminur pensando que aquele código pode ser reaproveitado em outro lugar. Por exemplo, uma lib de envio de e-mail/sms ou salvar arquivo (s3, google, local..) pode ser aproveitada em vários outros códigos. Então prefiro usar uma factory e apenas passar o tipo de serviço que quero. Por exemplo, na minha factory de "salvar arquivos" passo a instância que quero (s3, google...) e da posse desse objeto só passo o conteúdo que quero que seja salvo.
maioria desses padrões tem um uso muito específico, na maior parte dos casos é só placebo.
Primeiramente meus parabéns pelo iniciativa, gostei muito do tema.
Contudo particularmente eu não utilizaria à abordagem do video no dia a dia como sendo ideal, pois seguindo a linha do Gof e solid, design patterns são técnicas para soluções de problemas que antes ja foram resolvidos por outras pessoas, no caso usando "facade". o que importante no uso dos design patterns é motivacao para seu uso e quando aplicamos de modo superficial realmente não fará mto sentido, porém existe uma outra forma de se usar este pattern "Facade" em conjunto solid "decorator" e "strategy" e que torna coisa mais perto de uma best practice ou seja no caso menos acoplada e mais coesa.
No exemplo mostrado poderiamos precisar de diversas alterações para adicionar um único campo. Porém a aplicabilidade dos 23 Design patterns da Gof quando bem usadas são sempre boas praticas de projeto.
O acoplamento existe, mas se existir ele deve ser baixo.
@Leonardo B.A. Esses mensageiros de fato deixam o código com baixo acoplamento, mas são o inferno na hora de dar manutenção!
Mata a cobra e mostra a cobra morta, Isso sim é explicação de Design Patterns. Muito Bom !!! 👏👏👏
Obrigado pelo material, pessoal. Faz bem mais sentido quando vocês mostram o código, escrevendo linha a linha. Parabéns pelo conteúdo!
Achei interessante a proposta que vocês trouxeram. Isso nos força (no bom sentido) a questionarmos melhor quanto a utilização de algum Design Pattern.
Olhando exclusivamente para o ponto do acoplamento, uma das formas que pensei foi em utilizar um Abstract Factory.
ClienteAvatar, ClienteDocumentos, ClienteHistoricoAcesso, ClienteService e ClienteEmail, seriam as implementações das respectivas interfaces (produtos).
O Facade chamaria a fábrica, que teria a responsabilidade de criar essa família de objetos relacionados, mas trabalharia com interfaces, não com implementações.
Talvez ainda esteja ferindo o princípio da responsabilidade única, mas ao meu ver, estamos ferindo por seguir outro princípio muito importante: “Programe para uma interface e não para uma implementação”.
Todo Pattern vai apresentar suas vantagens e desvantagens (nunca vamos ganhar em tudo), temos que avaliar caso a caso.
Abraço, pessoal!
Curto muito vocês, sempre bem animados e com assuntos interessantes. Parabéns.
olha eu aqui de novo em vídeo antigo salvando minha vida
eu iria criar um service pra ser um concentrador de validação de regra de negocio pra diversos endpoints que algumas vezes podem editar o mesmo objeto e... um Sr de outro time me sugeriu... pq não fazer um facade?
antes de voltar no livro q li isso alguma vez e ja esqueci, logo depois de dar uma pesquisadinha no gpt pra refrescar a memória, venho aqui e vocês esmagadoramente resolvem deveras todas as minhas dúvidas rs
Parabéns vocês são show de bola.
Muito obrigado pelo carinho Pablo. 🤓
Gostei demais sobre a explicação do facade. Vai de cada empresa e sua arquitetura definir qual design Pattern aplicar, mas acho que tanto facade quanto solid são muito uteis.
Amei o vídeo, muito bem explicado como sempre ❤️
É inevitável quando começamos a pensar em camadas de abstração e encapsulamento de tarefas específicas, a gente não implementar o Facade. Na verdade eu acho que muitas pessoas já fizeram mas não perceberam xD
Bom, assim como o singleton, o Facade é um pattern muito controverso, eu usava bastante, mas hoje em dia acredito existir patterns mais apropriados para solucionar esses problemas de complexidade no lado cliente.
Talvez o Mediator para propagar uma mensagem para todos as classes envolvidas no subsistema para chamarem seus métodos remove e aí elas ficam responsáveis pelo processo, ou até mesmo padronizar todas elas com a interface e o método remove ser chamado num loop, dentro de uma lista das dependências dessa classe.
Enfim, eu sei que o exemplo de vcs foi demonstrativo, mas acredito que existam diversas maneiras para evitar jogar tudo nas costas de uma fachada x3
Mas realmente as vezes eh inevitável devido a complexidade do caso.
De toda forma, parabéns pelo vídeo!! Muito didático e bem formatado, como sempre.
Continuem com o assunto, por favor!!
Observer e Mediator agregam mais para manter coeso, assim podemos ter o Design Patterns, SOLID e até Arquitetura Hexagonal respeitados.
Caramba vocês estão arrasando com o conteúdo! Parabéns!!!! Me inscrevi no canal.
Um dos melhores do RUclips, parabéns para ambos.
Muito obrigado!!!
Parabéns pelo conteúdo, e pelas considerações finais sobre ambas arquiteturas, eu particularmente acho SOLID mais elegante, a aplicação quando pronta fica bonito de ver tudo funcionando, de next bora de arquitetura hexagonal?
7:19 (e assistindo), Como dev C#, eu faria essa implementação usando o container de injeção de dependência nativo do asp net Core, até esse momento da explicação (salvo engano) pelo menos o IoC e o DI eu já conseguiria manter! Fica o comentário para tentar contribuir na discussão sobre o tema, se alguém tiver algo a adicionar (concordando, discordando ou sugerindo) seria muito construtivo para a minha evolução! 9:15 Não posso encaixar um delegate por exemplo?
Muito bom, se ter que alterar em mais de um lugar, acho que melhor não.
Video extremamente didático! Mandem mais análises de design patterns.
Excelente vídeo! Falem mais sobre esse assunto, gostei bastante e creio que pode ajudar muita gente!
Eu comecei a estudar mais sobre esse tipo de coisa recentemente, e já tem me ajudado bastante, embora eu ainda esteja engatinhando no assunto asuhaus
Também venho aqui pedir uma playlist com todos os design patterns pois são muito úteis e ajudam muito a nós desenvolvedores
Na empresa onde trabalho, utilizamos facade em delphi, eu entrei depois que já estava implementado, só participo de manutenções, mas o que posso dizer, é que não é nada fácil dar manutenção nesses facade aqui kkkkkkkkk.
Por favor, fazem um vídeo sobre o observer partern. Vocês explicam muito bem amo vocês 😘
Sensacional! Gostaria de ver o já mencionado nesse vídeo Decorator pois como estou usando de forma ampla o typeorm no Node JS gostaria de entender como funciona exatamente por debaixo dos panos
Opa, minha sugestão: CQRS design pattern, é o pattern que estou usando atualmente junto com o Nest.js, é bem interessante, o Nest usa IoC e injeção de dependência para garantizar o mais alto nível de desacoplamento possível.
Eu uso bastante o facade para isolar os objetos de domain dos DTOs. Assim eu posso ter um facade para cada tipo de DTO mas sem mexer na implementação do domain
Excelente abordagem, muita gente negligencia esse assunto, mas DP é fundamental...
Muito obrigado!!!
Ótima abordagem. Neste momento estou mais tendencioso a usar um service no lugar do facade, parece mais fluido, mesmo sendo um pouco mais verboso.
Gosta muito do canal! Ótimo trabalho!
A mentalidade em usar Padrões de Projetos é ganhar produtividade em reutilização na prática (foguetes SpaceX) de soluções já conhecidas em projetos reais!
E com isso, liberar tempo para focar em problemas novos, não estruturados e desafiadores!
Sugestão: Padrões em soluções em Cloud e micro - serviços!
Gratidão!
É possível resolver o problema criando interface para cada serviço. Colocando no construtor do facade e criando uma interface ao facade tbm, aí quando o cliente precisar usar ele chamaria por resolvedor de dependência. A manutenção fica em: adicionar uma nova interface na implementação do facade e chamar seu método.
É o facade ficou acoplado pela implementacao que deveria injetar outras interfaces de subsistemas e se nao precisar garatir a ordem de execucao aliar com observers e segregacoes. O acoplamento seria minimo e respeitaria boa parte do solid. Em uml esses componentes sao descritos como controladores.
Com relação ao SRP para saber se quebrou ou não, deveríamos saber a quais atores os métodos pertencem . Se forem atores diferentes além de não quebrar, o próprio Uncle Bob recomenda.
Eu gostaria uma playlist com todos os design patters hahahaha
Ele simpático, ela uma fofura kkkkkk Muito Legal pessoal, curto de mais seus vídeos, já trabalho a muitos anos na área, porém volta volta e meio eu venho aqui dar uma olhada pq sei que sempre tem coisa boa!!! Sucesso para vocês!!!!
Muito obrigado pelo carinho Jeoás! Sempre bom ver comentários como o seu, volte à vontade. ;)
Muito bom, esclareceu muito minha dúvida. Agora a questão da business comunicando com a Facade. Podem explicar?
E se vc fizer o Facade e ao invés de instanciar as classes concretas utilizar um Service Locator para obtê-las? Isso tira o acoplamento do Facade, ao mesmo tempo que abstrai a complexidade para o client.
Sem dúvida Carlos! O Service Locator é uma boa solução, nos deu até uma ideia para os próximos vídeos. ;)
@@codigofontetv ai sim, top!
Facade é aquilo que mantem o dev de 10 anos de experiencia no sistema necessário.
para a lgpd no "apagar o histórico", por conta de lei é possível avisar o cliente que não pode ser apagado no prazo legal, gerar um agendamento de exclusão futura, ainda deve usar o critério de pseudo-anonimização para a exclusão futura
Estou lendo o livro Clean Arch, e ele já inicia com SRP, no trecho que ele fala de fusão que é um dos sintomas de se quebrar esse princípio, uma possível "solução", isso para não chamar gambiarra, se pode usar o facade, então não se enganem, Robert Martin só exemplifica isso como um paleativo técnico, kkkk, quando a #¿$?%!¡ já ta feita, isso é minha opinião.
Muito bom o vídeo, como sempre =] Obrigado por compartilhar esse exclente conteúdo
Muito obrigado Fernando pelo feedback e por sempre estar conosco aqui no canal. Grande abraço!
Entendo que valeria a pena considerar nessa análise que os design patterns GoF são de 1994 enquanto os SOLID do Uncle Bob são de 2000. Na minha humilde opinião (hehehe), por serem anteriores aos SOLID, entendo que essas alegadas violações são bem compreensíveis e aceitáveis.
Falem sobre os patterns Proxy e Mediator
usamos facade pra esconder as chamadas à DLLs, ate q não temos tanto problema. Complica se tenta usar em outros casos.
No meu ponto de vista, tudo depende de qual a intenção por detrás da implementação. Se é oferecer uma interface mais simplificada para quem for consumir os serviços, o Facade pode ser uma boa solução. O SOLID trabalha mouito com interfaces e interfaces nos liberam para implementações das mais variadas, o que nem sempre é uma boa solução. Por outro la não acho que um Facade quebre o single Responsability, se pensarmos que a responsabilidade dele seja agregar os serviços.
Não se se ja tem vídeo mas gostaria de ver o composite.
Olá, de acordo com Uncle Bob (criador do SOLID), o Facade pode ser usado para ajudar na implantação do SOLID, especificamente no **S**(SRP). O ponto aqui é que a implantação feita de Facade neste vídeo não foi legal, mas se bem feita, ele (Facade) ajuda na boa manutenção e desacoplamento do código. Basta olhar o livro do próprio Uncle Bob (Clean Architecture), quando ele fala de SRP e dá exatamente o exemplo do Facade (figura 7.4 do livro) como boa prática para implantação de responsabilidade única.
Adorei o video showwwww de bola.
SOLID 'força' interfaces para maior desacoplamento, mas cria uma camada de burocracia que pode ser mais trabalhosa que altera aqui e alí (fora o debug que fica horrível). Por isso acho que interface (como qualquer outra prática) deve ser aplicada quando FAZ SENTIDO, então se instanciar a classe direta ou mesmo usar Façade ferir o SOLID, paciência pro SOLID (querer implementar o SOLID perfeitamente é estar mais preocupado com a estética do que com a efetividade do sistema).
O maior problema do solid é que ele é dificil de absorver, porém, depois que vc entende de verdade, fica quase que lógico o que fazer em um projeto. A camada de 'burocracia' que o pattern adiciona não está la para te atrapalhar, pelo contrário, ela deixa exposto em um unico ponto o que o seu sistema é capaz de fazer. E a questão do debug, depende muito de IDE pra IDE, eu recomendo as da Jetbrains e pelo contrario de vc, eu acho debugar projetos solid uma coisa fluida e natural, talvez suas ferramentas não estejam te ajudando da forma como deveriam ...
@@oalef3411 Minha experiência em debugar e navegar em entidades com interfaces foi muito ruim (pelo menos, não gostei)... não estou dizendo que solid seja ruim, mas implementar ele 100% não, já que interfaces só deveriam ser usadas quando realmente fossem necessárias, do contrário, é adicionar burocracia e complexidade onde não precisa. Como analogia, é como querer no banco de dados que tudo esteja na 4FN para desacoplar tuplas compostas deixando tudo indexado. Na teoria é lindo, mas na prática, nem precisa dizer o trabalho de mapaeamento e quantidade de joins que isso irá resultar (e é como o solid abordaria o banco de dados).
@@pgnt Acredito que se utilizar 100% o SOLID, fere o princípio de deixar o mais simples possível.
@@pgnt Entendi seu ponto, porém sua conclusão está equivocada, tipo, realmente solid não faz sentido aplicado em um banco de dados, até porque os bds tem seus próprios paradigmas. O fato de depender de interface é algo que é justamente maravilhoso, pois, vc pode escrever um código base e nunca mais precisa tocar nele novamente, enquanto adiciona novas funcionalidades facilmente.
É como um contrato, que vc assina com o seu código, se vc pensar no seu código como seres, é a mesma coisa que a classe que depende de algo, estar contratando uma empresa que faça x coisa, invés de contratar o josé antonio que também faz essa coisa, só que do jeitinho dele...
Custando o mesmo preço, vale muito mais a pena contratar a empresa que segue os padrões do que o seu josé antonio ou o marco aurelio ou qlq um que faça o mesmo trabalho porém de maneiras levemente diferentes...
@@oalef3411 Blz, ainda prefiro usar interface só quando necessário pois daí saberemos que existem outras classes correlatas (e sem ficar preso à implementação burocratizada).
Quero ver o Observable e o Singleton
Eu tentaria implementar uma arquitetura orientada a eventos, quem sabe utilizando Domain Events para tentar diminuir a complexidade, o acoplamento e continuar a seguir o solid.
puts, adorei usarem typescript
Concordo!
Quando a gente faz o acoplamento de forma consciente (sabendo no que isso irá implicar), não é tão ruim assim. O problema é codar sem pensar e deixar um rastro de destruição por onde passa.
Proximo Design Pattern poderia seria o Observer
Fantástico
Um method de um FACADE poderia ser trocado por uma classe na camada USE CASES e uma Factory pra popular todos os servicos que esse cliente esta registrado?
Por exemplo:
import 'RemoveCliente' from '../usecases/RemoveClient';
new RemoveCliente(new FactoryPegarServicosDo(client)).run();
Adoraria ver um sobre DDD
Notem que "facade" é na verdade a palavra francesa "façade". Pela pouca disponibilidade de "ç" nos teclados de língua inglesa, é comum escrever-se "facade". Mas a pronúncia da palavra em inglês imita a leitura francesa, então se lê "FAÇÁD", e não "facêid" (e muito menos "fakêid").
É só mudar o nome de facade para service. Pronto, problema resolvido.
Gênio!!! 🤣🤣🤣🤣
Perfeito
huahuah pensei a mesma coisa!
Até você iniciar o teste 😂
Pra Refatoração de sistemas um facade funciona perfeitamente (strangle pattern)
Qual o padrão que gostaria de ver? Padrão FIFA!
Deve ser massa fazer pair programming com a esposa o dia todo. 😁
Quantos design patterns existem?
Uma dúvida, conseguimos trocar o facade por um chain of Responsibility?
Esse Facade me parece muito um Helper. Algo como um:
class FacadeCliente {
static removeContas(List clientes) {
clientes.forEach(cliente => cliente.Remove());
}
}
Seria uma boa?
Muitos dos problemas que se tenta resolver com Facade, podem ser resolvidos com Observer.
Neste mesmo exemplo do video, eu poderia emitir um Event/Subject ( clientRemoved ) para todos os Listeners previamente registrados.
O sistema fica o menos acoplado possível e os princípios de SOLID são respeitados, ou o menos desrespeitados possível.
Isso também expandiria as minhas possibilidades: enfileirar o processamento/transmitir para uma lambda function remota, notificar as partes interessadas no evento clientRemoved com um Broadcasting etc.
Isso não traria ainda mais complexidade? Vale a pena trazer toda essa complexidade apenas para seguir os princípios SOLID?
@@nataestanislaubastos7637 Cara, complexidade não tem nada a ver com SOLID, uma coisa pode seguir o principio da responsabilidade única, ou qualquer outro princípio, e ser complexa, a questão é que usar o observer dá muito mais flexibilidade pra dar manutenção, e dessa forma fica mais desacoplado, mas isso é subjetivo às necessidades do seu projeto...
Concordo, genial inclusive!
@@nataestanislaubastos7637 Este é um dos princípios não é mesmo? D
@@nataestanislaubastos7637 Os princípios SOLID é pra você poder modificar o código e adicionar novas features sem medo de quebrar outras partes do código...
Ai vem a pergunta, oq é mais complexo: Ter que verificar todo o sistema toda vez q alterar algo ou simplemente alter?
Adorei o vídeo! Eu tinha curiosidade de saber o q era esse Facade q aparece nos scripts , mas sou novo em programação. Valeu ! Vcs oferecem cursos de programação online?
E o facades do laravel? Não tem esses acoplamentos
Agr pronto, fiquei foi mais confuso... Eu cai nesse vídeo porque o Uncle Bob usa o Facade pra aplica o SRP enquanto fala do SOLID no livro Clean Arquitecture e tão detonando o Facade justamente nesse contexto .-.
imagina se estoura uma exception no meio daquele removeConta, dor de cabeça garantida
Falem sobre Page Objects por favor :)
Ninguém usa mais FACADEs que os laravel! ahhaha
Facede é o famoso garçom kkkkkk Ele ajuda a aplicação a se tornar mais reutilizável.
O facade pode ser substituído pelo composite e assim o solid é mantido
próximo Design Pattern poderia ser builder
Solid
Vlw!!
A voz da Vanessa é igual à da mãe do Chris do "Todo Mundo Odeia o Chris"! Ela podia ser dubladora! rs
Estou tentando me concentrar no que estão dizendo, mas perco todo o raciocínio quando vocês falam de host gator e eventos paralelos.
Uma coisa que me desagrada é fazerem merchan a cada minuto.
Não estou dizendo para não fazerem, mas poderiam colocar somente no começo e final do vídeo, NÃO no meio.
Deixem um joinhia se você concorda também.
Muito obrigado por esse feedback! É importante pra gente saber essas coisas. Vamos reavaliar aqui o posicionamento dos inserts nós vídeos.
Confesso que não consegui escutar até o final, mas independente disso a iniciativa é muito legal e o conteúdo é uma dos meus favoritos. Não me interpretam mal, mas precisamos ajudar o mercado a pronunciar os nomes técnicos corretamente, já que existe muito bons técnicos no Brazil, porém o inglês... parece desnecessário mas pronunciar corretamente faria o conteúdo muito mais interessante de se ouvir.
Marco, entendo e repeito o seu ponto, mas gostaria de acrescentar de forma respeitosa que tenho em mente que se o foco em geral é se comunicar, fazer com que o conteúdo/mensagem seja entendido com sucesso pelo receptor, ótimo! \o/
Lembrando que sim, evoluir/aprimorar a sua grámatica/pronúncia são extremanente válidas. :)
Mesmo os termos técnicos em palestras muitas vezes são péssimos, mas se objetivo de comunicação foi alcançado, a galera não liga... Me parece mais uma preocupação de BR. :(
p.s: Vide os videos dos indianos ensinando alguma tecnologia. rsrs
@@viniciusmattosrj concordo contigo. A mensagem eh o mais importante, mas vale a pena aprimorar. Vai valer a pena o dia que tiver que fazer um palestra ou estiver em um time cuja o idioma seja Ingles. Mano... em relacao ao seu comentario dos Indianos. 100% de acordo contigo!
Massa!!!
De próxima vez que alguém reclamar que meus códigos estão confusos e bagunçados, já sei o que responder.
Não é isso! É que eu estou usando o Facade.
kkkkkkkkkkkkkkkk
Valeu.
Sou favorável ao uso do facade para casos comuns, como envio de email, log, instância de banco, etc. Mas para funcionalidades não, aí prefiro usar outras estratégias
A LGPD foca mais nos dados sensíveis... email. CPF, endereço... Vc pode apagar esses dados se solicitado mantendo o registro e assim não removendo as pks nem quebrando os relacionamentos com as fks.
uma coisa. vcs colocara : boolean em metodo sendo q ele sempre retorna true... inferencia de tipo... o : boolean esta redundante
Não está redundante, quando vc infere um tipo significa que quer o retorno específico. Em projetos onde mais de um programador atua, esse tipo de usabilidade é extremamente importante. Na dúvida é melhor o dito do que não dito, pode ser óbvio pra um mas não pra outro e na prática vale o que ta escrito.
@@chewbacca01 discordo. esta redundante, o typescript n é como java ou c++ ele tem inferencia de tipo so se deve declarar onde o ts n consequiu predefinir... n faz o menor sentido por exemplo o codigo abaixo
const age: number = 13;
o ": number" é algo q n é necessario o ts e nossa ide conseque enteder q é um numero. no caso do ": boolean" o retorno sempre é true ent sempre sera boleano TALVEZ se puder retornar uma string por exemplo teria q por ": boolean | string" mas depende do caso... e msm assim se sua função ta retornando dois tipos diferentes acho q tem algo errado nessa historia, talvez responsabilidades demais. enfim n era necessario mas n é errado so é verbosidade atoa na minha opinião.
PS.: e a questão de mais devs no time se eles usam uma ide concerteza ja sabem o tipo desta variavel.
@@mateushenrique6421 criaram o Typescript justamente para que possamos tipar nossas variáveis. A tipagem tem seus benefícios. E outra, se você não inicializar a variável não tem como saber o tipo dela. Atributos de classe não são inicializados na maioria das vezes. Se eu fosse a Microsoft teria tornado obrigatória a tipagem de todas as variáveis no TypeScript, assim como é no C#.
@@rcosta7239 ss mas foi implementatada a inferencia de tipos q conseque defeinir o tipo sem que precisamos definir neste caso n era necessario ja foi predefinido pelo typscript.... e a tipagem obrigatoria é para linguagens fortemente tipadas o ts é de tipagem fraca mas estática.
PS.: mas em alguns casos a inferencia de tipo n conseque definir e nos prescisamos coloca-lo
Mostra pra gente como seria escrever e manter um código orientado a gambiarra, só pra ter uma idéia do inferno e do que não fazer!
Dizem que o Generics também é um anti-pattern , mas usando o specification pattern isso é contornado
Se envolver DDD, CA aí sim SOLID complica rsrs
Eu as vezes faço de conta que isso não existe 🤦♂️😂
Quando quiser adicionar funcionalidades vc cobra o suficiente pro cliente desistir
Next: Proxy
State x Strategy
Curiosidade: Pronuncia-se "Fêssádzi", não "Fácêidi".
Design Pattern deveria ser OBRIGATÓRIO em graduação de TI
Você tem toda razão! Nós mesmos fizemos Ciência da Computação e aprendemos estudando por fora da faculdade.
Graduação em TI é 70% lero-lero e que de fato importa sequer é mencionado.
@@danielneto6619 Isso por que graduação em Ciência da Computação não é só sobre design patterns e desenvolvimento, é sobre COMPUTAÇÂO. Se espera aprender a linguagem do hype, é melhor fazer um curso na udemy do que uma faculdade. Tem muito conhecimento em ciência da computação que não faz sentido nenhum pra quem quer trabalhar como desenvolvedor de sistemas, assim como aprender SOLID pode não ser uma prioridade pra quem vai trabalhar com computação distribuída ou fazer pesquisa com machine learning ou teoria dos grafos. O problema é que as pessoas sempre entram no curso com a cabeça de que o único emprego que existe dentro da tecnologia é ser programador.
Deixei meu like .
Muito melhor sem jaleco!!!!!!!!
Facade é uma "farsa", simplicidade de um lado, complexidade do outro. kkkkk
padrão :"Strategy"