Hoje a gente viu bastante coisa, bastante padrão, quase três horas de aula. Então, a gente passou pelo DTO, pelo repository. Entramos fundo do repository nos termos do aggregate, que nem é tanto o escopo da nossa aula, mas é do padrão. Usamos adapter em mais de uma ocasião. Usamos adapter para criar a conexão com o banco. Usamos adapter para montar o servidor HTTP. conexão com o banco. Usamos a DAPDA para montar o servidor HTTP. Usamos strategy para fazer um comportamento intercambiável. Criamos uma dynamic factory para instanciar com base em uma string. Criamos um presenter para converter dados. Olha que importante. Cadê o presenter? Aqui. importante. Cadê o presenter? Aqui ó. CSV presenter. Ele é responsável por formatar, por criar um formato tipo um CSV. Podíamos associar em content negotiation, por exemplo. O que eu quero dizer com content negotiation? Aqui eu poderia detectar o header content type, dependendo do Content Type eu uso um ou outro Presenter. Poderia ser o caso. Fizemos um decorator para estender as capacidades do nosso Use Case Generating Voice. Como que a gente fez isso? Criamos uma interface comum e criamos o decorator para logar todas as chamadas feitas poderão ser vários, inclusive o que mais? controller para receber as requisições, composition root que é o main, mediator para conectar objetos que não devem se acoplar de uma forma mais suave. Então, vimos bastante coisa. Falamos de Solid Principles também. Mostramos o Single Responsibility, quando a gente juntou muitas responsabilidades que não tinham relação. Dependency Inversion Principle, quando a gente investe a dependência passando o repositório por parâmetro, passando a Database Connection por parâmetro, passando a database connection por parâmetro. Open, close e principal quando a gente cria um ponto de extensão, como no caso do strategy. Não falamos aqui de list of substitution principle e de interface segregation principle. Mas antecipando, a list of substitution principle tem a ver com a coerência na Interface Segregation Principle, aí antecipando, a Lichical Substitution Principle tem a ver com a coerência na hierarquia. Ou seja, é você respeitar a invariança dos objetos, que é o estado interno, você não estender, ter que implementar métodos que você não precisa, você não retornar valores incompatíveis com a superclasse. Tudo isso tem a ver com o discalque substitúrgico. E, no fim, o interface aggregation serve exatamente para você decompor em mais interfaces menores, com menos funcionalidades, para que você tenha a capacidade de estender só aquilo que você precisa. Então, o Solid Principles tem total relação com os Patterns que a gente viu. E eu recomendo bastante que vocês leiam aqueles livros que eu estava comentando. Livros, né? Gang of Four, um projeto clássico. Tem também o Headfirst, Design Patterns. E também o Patterns of Enterprise Application Architecture. Esses são os livros que eu recomendo bastante. Beleza, pessoal? Vai ser tranquilo? De boa? Opa! Que aula, hein, Branas? Exato. Eu acho que é muito bacana a forma como você apresenta e eu acho que esse é um dos principais motivos que eu me inspirei para falar poxa, o Branas tem que participar aqui porque eu já em especializações que eu fiz e tudo mais, eu já caí em momentos de assistir aulas sobre design patterns, que a pessoa vai lá, ela pega todos os patterns e mostra o ML do pattern e fala intenção, para que que usa e olha como é que ele é. Mas, no final do dia, você sai com um monte de diagrama ML e é muito difícil de você imaginar como que você, no final do dia, vai utilizar. Uma outra questão muito comum é o quê? É você estudar design patterns e daí, de repente, você tá com os exemplos. Gato mia, cachorro late, um papo boa, eu tenho um quadrado com um triângulo, com um retângulo. A pizza, né? Desse tipo, daquele tipo. Exatamente isso. E poxa vida, isso é muito longe da realidade que a gente está... No dia a dia mesmo, né? Exatamente isso. É muito distante da realidade. Eu sou... Eu assumo... Eu aprendi design patterns realmente quando eu codificava, via aquela situação que não estava legal, como que eu refatório isso? E depois eu ia atrás dos patterns e falava, poxa, essa é uma solução bacana. Então, quando você consegue juntar a forma como você fez, apresentando o problema, vendo um código inteiro bagunçado, gritando, por favor, me refatore ali, e sabendo quais são os patterns que mais se adaptam ali, eu acho que fica muito mais claro. E uma coisa também que eu gosto muito, principalmente quando você está trabalhando de forma prática independente de linguagem de programação eu gosto muito da utilização do TypeScript nesse caso porque ela é uma linguagem extremamente neutra então se você vem de PHP você entende se você vem de Java você entende se você vem de C Sharp você entende então se você vem de Python, você entende. Se você vem de C Sharp, você entende. Então, se você vem de Python, provavelmente você vai entender. Então, raramente uma pessoa que trabalha com orientação a objetos vai ter alguma dificuldade, de forma geral, de entender sintaxe, implementação e etc. O que eu gosto também é que você trabalha nesses casos também com TypeScript bem vanilla evitando um monte de map reduces e etc é bem, porque a linguagem é neutra, ela tem que passar batido exatamente, para ela não ser algo que acabe gerando esses tipos de coisa, uma outra coisa que eu gostei também é que, apesar de, normalmente quando a gente fala de cara em design patterns, o Goff vem na nossa frente, o Gang of Four vem na nossa cara, mas no dia a dia, não tem como. Você está trabalhando eventualmente com o DDD, você vai ter que acessar um banco de dados, você vai ter que fazer componentes eventualmente se comunicar, você vai ter que apresentar as informações de diversas formas. O presenter, da forma como você colocou, tem muita gente e olha só que interessante, Breno. Eu já falei com muita gente, caras que manjam demais, mas assim, o dia do cara tá tão ligado a trabalhar com REST, que ele nunca, nem na cabeça dele se pensou que o formato do dado que ele entrega poderia ser alterado de acordo com o driver que tá se encaixando ali, né? Daí eu falar pra ele, cara, e se você estiver trabalhando com um API HTTP, mas você tem que entregar os dados em gRPC no momento, você tem que entregar, enviar essas informações também através de uma fila, que vai ter que vir em um outro projeto. Agora vai ser um tópico do Kafka, vai ser com o RabbitMQ. E todos esses caras exigem uma assinatura, um esquema diferente de entrega. Então, se você acopla o seu código da forma como você vai apresentar, fica muito mais complexo nessas situações. Porém, só para você fazer um adendo aqui também, Branas, até que ponto a gente deve chegar nesse nível de detalhe? por exemplo, eu sei que a minha aplicação de forma geral, a chance de ela trabalhar com sei lá, com gRPC é mínima provavelmente vai ser uma payrest, etc você acha que por padrão eu devo lá criar uma interface de presenter criar o presenter, botar lá no use case e fazer tudo isso, sendo que, provavelmente, se eu for adicionar um outro formato, vai ser daqui a um ano. Eu vou te dar um exemplo que eu passo bastante hoje em dia. Eu trabalho, como eu te falei, muito em software financeiro contábil e a gente integra, às vezes, com SAP, integra com Senior, integra com várias empresas que têm formatos diferentes. Só que o meu use case, esse caso que eu mostrei é um caso muito real. Então, quando eu vou gerar o dado para o SAP, o que muda? O formato do arquivo. Quando eu vou para o Senior, é outro formato. O cliente, às vezes, quer um formato neutro, quer um CSV simples para ele fazer uma conferência. E o que varia nesse caso? O presenter. Então, o mesmo use case que fala me dê o movimento de caixa do mês de março de 2023, só que me entregue o DTW do SAP. Onde é que está o DTW do SAP? Está no presenter. Onde é que está o DTW do SAP? Está no Presenter. Onde é que está o do Senior? Está no Presenter. Então, essas combinações entre qual use case com qual Presenter dá muito poder. E ainda com o domínio embaixo, fazendo toda a parte de negócio. Então, quando você consegue separar bem essas coisas, eu vou te falar, esse Presenter que a gente fez, um CSV simples, eu, esse Presenter que a gente fez é um CSV simples, tá? Eu tenho um Presenter de 200 linhas. E é formatação, né? É trabalho muito manual, né? Como se estivesse esculpindo alguma coisa. Eu vou te dar um exemplo do caso do SAP, inclusive, tá? O Presenter tem que fazer duas coisas, ele tem que gerar dois arquivos. Por quê? Porque um arquivo é a nota fiscal, uma linha para cada nota fiscal. O outro arquivo é um item da nota fiscal do arquivo. E entre eles, você tem um código de sincronismo. Então, você vai ter o 1, 1, 0, 1, 1, 1, 2, que seriam três itens na nota de cá. Aí, a nota 10 aqui tem zero, tem um item aqui aqui, aí a 11 tem zero e um aqui amarrado também, você converte códigos, você tem formatos de datas você tem colunas que são específicas cara, no fim você está cheio de demanda que às vezes a correção é só no Presenter todo o resto está certo, o Presenter segue errado porque o formato é errado formato do TF bota boom na frente, tira muda muita coisa então, zipa enfim agora se você está trabalhando com uma API você acha que vale a pena fazer sem presenter, sem nada e se cair um outro formato aí eu faço isso aí pode ser, porque pra muita gente é só REST, né, para muita gente é só REST. Para muita gente é tudo REST. Então, o que eu diria? Pega o use case, usa na API, devolve o próprio output dele, que já é JSON, e seja feliz. Agora, começou a aparecer, mas aqui eu quero exportar, mas aqui eu quero converter em PDF, aqui eu quero fazer tal coisa. Aí talvez valha a pena olhar e ver se faz sentido ter essa responsabilidade. A gente confunde muitas vezes porque o próprio Clean Architect, quando mostra os diagramas dele, ele mostra num tipo de aplicação que o front-end e o back-end estão juntos. Por isso que você tem no mesmo lugar a graphic user interface, você tem o viewmod e você tem o presenter. Mas, na realidade, de 90% das pessoas, front-end é uma coisa, back-end é outra então você muitas vezes tem por exemplo dos dois lados entendeu? Exatamente por isso que eu confundi por que eu estou falando isso, Branas? porque, assim, eu não sei o nível você que eu estou falando agora com você não com você, Branas, mas com quem está assistindo a aula o nível técnico que você tem e o quanto você já manja design patterns. Mas eu quero evitar que você caia em algo que normalmente é uma doença muito grande que todos os desenvolvedores um dia têm. E eu quero que você diminua os sintomas dessa doença. Uma doença chamada de patternite. Quando você começa a aprender design patterns, você quer sair usando design patterns em tudo, criando um trilhão de interfaces, criando presenters, fazendo milhares de coisas, sendo que a sua aplicação não precisa disso. Então, assim, tome muito cuidado em você utilizar os design patterns para situações que realmente façam sentido no dia a dia, porque não adianta você sair criando um trilhão de abstrações, porque tem um ponto muito importante, principalmente quando a gente está falando em arquitetura de software. Uma coisa é importante você conseguir abstrair. Abstrair ajuda a gente a desacoplar. Mas quando você quer desacoplar muito, você aumenta muito a complexidade também. Agora, se você não desacopla nada, você tem também uma complexidade, uma fragilidade muito grande nos seus componentes. Você mexe um negócio e quebra o outro. Então encontrar esse meio termo desse desacoplamento, esse nível de abstração, eu acho que é aí que é a grande sacada de um bom desenvolvedor. O cara conseguir encontrar o equilíbrio de acordo com o contexto e o momento que o projeto está indo. Conforme o projeto vai ficando mais complexo, você vai ter que ir abstraindo mais para conseguir segurar todas essas fragilidades que o projeto pode ter. Mas você tem que conseguir dosar isso ao longo do tempo. É isso que é difícil, porque às vezes a gente quer usar muito. Eu acho que todo mundo que está iniciando, às vezes, sente um pouco de insegurança em achar que o que está fazendo é muito simples. Quando, na verdade, a simplicidade é a elegância, é o objetivo, é o que a gente deveria buscar, né? Então, às vezes, você olha e diz assim, ah, não, isso que eu estou fazendo é muito simples, eu tenho que complicar. Isso inconscientemente, né? Ah, então eu vou, nossa, vou comunicar todo mundo com o mediator, eu vou de repente colocar decorator em tudo, botar presenter em tudo mas às vezes não precisa então talvez sinta a necessidade de usar e aí você corre atrás, às vezes você está usando uma coisa e nem sabia que tinha esse nome padrões como Composite, por exemplo a Dom é um exemplo, mas tem uma árvore de componentes e você faz Get Children, Get Parent, vai navegando. Dependendo da tua proposta, você chega naturalmente, você usa anos sem saber que tem um nome, o padrão. Então tem muito disso, né? Perfeito. Doutor Rodrigo Branas, muito obrigado por esse show de aula. Eu não tenho dúvidas aí que o pessoal vai curtir muito. Depois eu vou pegar todo esse fonte, vou pegar esse documento lá, aí também, pra disponibilizar aí pra todo mundo servir como nota também aí de... não nota de matéria, né, de grades, mas como anotações mesmo para ajudar Perfeito, cara. Obrigado Valeu, doutor Rodrigo Branas muito obrigado pela aula e é isso aí Tá legal