Olá pessoal, tudo bem? Hoje a gente vai iniciar aqui uma aula absurdamente fantástica que nós vamos ter com o meu querido amigo Rodrigo Branas. Rodrigo Branas, eu vou deixar ele mesmo se apresentar, mas o nosso principal foco aqui é a gente conseguir trazer para você, de uma forma bem prática, mas ao mesmo tempo trazendo os principais conceitos quando a gente está falando de solid, os princípios solid e também uma série de design patterns que normalmente você vai encontrar no dia a dia conforme você vai desenvolvendo softwares. Então, estou passando aqui para o Branas, para ele poder falar um pouquinho mais dele e para a gente começar aqui a entender qual que é o nosso, qual que é o objetivo que vai ser cumprido hoje aqui durante essa nossa aula. Fala Wesley, fala galera, muito bom dia, boa tarde, boa noite, um prazer estar aqui, fiquei muito feliz pelo convite, principalmente para falar de um assunto que eu acho que todo mundo sempre gostou, sempre se dedicou, e é sobre os design patterns. Eu acho que desde os anos 90, quando a gente começou a ver esse assunto aparecendo cada vez mais, não só no mercado, como principalmente divulgado por muitos autores. Vale lembrar que a gente não tem só os design patterns presentes nessa obra, que é a mais clássica, que é do Gang of Four, mas também você tem Java 2.0 patterns, você tem patterns of enterprise application architectures, você tem vários tipos de padrões. Antes de começar, eu queria me apresentar. Então, meu nome é Rodrigo Branas. Eu programo há mais ou menos 20 anos e, de lá para cá, sempre trabalhei com sistemas enterprise, então muito na área financeira, contábil, fiscal. Nos últimos 10 anos, pelo menos, eu tenho me dedicado muito a isso. E é um tipo de software relativamente mais complexo em termos de regras de negócio, todo software tem a sua complexidade, alguns deles tem essa complexidade na infraestrutura, eles tem que receber uma grande quantidade de acessos de requisições, isso por si só é um desafio, outros muitas vezes tem um desafio mais ligado a negócio, como eu estava falando, onde você tem regras que mudam o tempo todo, que por si só dão muito trabalho para implementar, para testar e oferecem muito risco. Então, às vezes, uma implementação errada faz com que você emita uma nota fiscal de forma incorreta, eventualmente você pode até sofrer uma fiscalização, uma multa. Então, isso para ressaltar que o software que a gente faz é algo muito sério, muito importante. É importante que ele esteja correto. E aí os design patterns, eles aparecem naturalmente na maior parte dos sistemas, só que vai depender muito do design que a gente usa. Então, geralmente quando a gente fala dos design patterns do Gang of Four, você vê que o próprio livro já diz, né? Objects oriented. Então, boa parte deles tem relação com orientação objeto. Usam recursos da orientação objeto, mas não que você não possa usar muitas vezes em outros tipos de linguagens, às vezes linguagens funcionais, algum tipo de composição, muitos deles são viáveis. O design patterns, eles surgiram, o termo talvez começou a aparecer no final dos anos 80, e aí você vê pessoas muito conhecidas até hoje, como Kent Beck, autor de Action Programming, criador do JUnit, grande evangelizador de testes, um dos signatários do Manifesto Ágil, e também o Ward Cunningham, o Ward Cunningham, criador da Wiki, e também uma das pessoas que acionou o Manifesto Ágil, tantas outras como o Martin Fowler, o Robert Martin, o Alistair Coburn, outras como o Martin Fowler, o Robert Martin, o Alistair Coburn, muitos deles a gente já conversou, eu, Wesley, a gente já fez live com algumas dessas pessoas. E aí você começa a ver esse movimento indo muito numa direção técnica no final dos anos 80. O que se buscava muito na época era como eu posso entregar software melhor, mais rápido, com mais qualidade. Muitas analogias, até mesmo com processos de construção civil foram feitas. Quando você vê processos similares a waterfall, a cascata, você começa a ver que existiam grandes etapas de planejamento, seguidas por muitas etapas de análise. E aí você começou a ver assuntos como a UML emergindo, Unified Modeling Language, que na prática foi a unificação, por isso que é Unified, de outros métodos que vieram do Ivar Jacobson, do James Humble, do Grady Butch, e que deram origem a esse meio de você se expressar por meio de diagramas de classe, de sequência, de atividade. Por quê? Porque você tinha uma grande ênfase numa etapa de análise. E muitos patterns vieram justamente nessa época. Muitos patterns são explicados até hoje por meio de UML, desenhando como as classes envolvidas colaboram. Então, é muito comum que quando você começa a estudar design patterns, você passa, naturalmente, a olhar alguns diagramas, algumas setas e se questionar, peraí, mas por que essa seta tem um triângulo na ponta e a outra não? Então, por que essa tracejada aquela não e aí você começa a mergulhar nesse mundo e vê que os design patterns nada mais são do que soluções comuns que você muitas vezes chegaria naturalmente às vezes uma simples interface que você implementa e você varia um comportamento de maneira polimórfica, muitas vezes já recebe um nome. Muita gente chama de strategy. É um dos padrões de comportamento. Às vezes você simplesmente converte uma classe na outra. Tem gente que dá o nome de adapter. Quando você faz essa conversão entre diferentes interfaces, propriamente ditas, você está criando uma espécie de wrapper. Quando você tem algum tipo de padrão que notifica algum objeto, muito comum para quem trabalha na web, para quem está acostumado a criar um list de um botão, se dá o nome de um padrão, como, por exemplo, um observer. Então, os padrões são mais comuns, eles são mais triviais do que a gente imagina. Eu acho que a gente tem que justamente encarar os padrões com mais naturalidade para que você não necessariamente tenha que premeditar o uso de um padrão. Ah, eu preciso tanto usar dez padrões aqui nesse livro, deixa eu ver onde é que eu consigo encaixar. Não, simplesmente você está desenvolvendo e ele de fato resolve um problema seu. Agora, esses padrões, eles só vão resolver o seu problema se o design que você adotar, muitas vezes, te permitir. Eu vou pedir para o Wesley colocar na tela, de repente, a minha... Isso, show de bola, Wesley. Então, eu sempre, que estou dando aula de alguma coisa e lembro de mostrar esse diagrama aqui. Ele é muito legal porque ele evidencia uma realidade que muitas vezes a gente não percebe, que é o seguinte, todo código que a gente escreve, ele obrigatoriamente está apoiado sobre uma decisão de design. E essa decisão de design é restringida por uma escolha de arquitetura. O que eu quero dizer com isso? Quando a gente escreve qualquer código, a decisão de colocar uma responsabilidade na classe A ou B, ou mesmo de usar classes, mas aí já é outra discussão, mas colocar a responsabilidade na classe A ou B, fazer com que B chame C, fazer com que C receba um parâmetro do tipo D, essas decisões começam a demonstrar como que é essa relação e isso se expressa por meio de um design. Design Patrons nada mais são que isso, responsabilidades distribuídas em diferentes participantes de um determinado trecho do teu código. E por que eu disse que a arquitetura restringe? Ora, se você usa uma linguagem, se você decide usar uma linguagem que é procedural, você vai ter um tipo de design possível. Se você usa uma linguagem funcional, você tem outro design possível, ao passo que Se você usa uma linguagem funcional, você tem outro design possível, ao passo que se você usa uma linguagem orientada a objetos, você tem outras possibilidades. Então, a arquitetura é esse conjunto de decisões difíceis, só que, ao mesmo tempo, muito importantes, que você toma, geralmente, no início de um projeto. Normalmente, a gente escolhe o framework, a gente escolhe o paradigma, a gente escolhe o tipo. Muitas vezes de divisão, vou usar um termo aqui do domínio de design, dos nossos bounded contexts, que no fim do dia podem proporcionar a criação de microserviços, muitas vezes são definições que a gente toma lá na arquitetura, lá no início de um projeto, você já vai começando a distribuir as equipes, você já vai tomando decisões que vão, sim, impactar o teu design, impactar as responsabilidades que você é capaz de atribuir. Então, ao longo da aula de hoje, a gente vai ver muito sobre isso, muita decisão de design, tá bom? Show de sobre isso, muita decisão de design, tá bom? show de bola então pessoal os padrões de projeto eles se dividem, e aí é bom que a gente entenda isso, então o padrão de projeto nada mais é do que algo que alguém observou ao longo do tempo que se repetia muito, por isso formando um padrão, posso ressaltar aqui os padrões do Gang of Four. O Gang of Four é composto por quatro autores, liderados pelo Eric Gama, que está aqui liderando a capa do livro, mas também seguido pelo Richard Helm, Ralph Johnson, John Blasides. Então, os padrões do Gang of Four talvez sejam os mais conhecidos. Como eu estava falando, você tem os padrões também. os padrões do Gang of Four, talvez sejam os mais conhecidos. Como eu estava falando, você tem os padrões também. Na época do Java EE, as primeiras versões do Java Enterprise Edition, você trouxe muitas decisões arquiteturais, como por exemplo, usar componentes remotos que rodavam em JVMs diferentes e isso começou a te trazer ideias de que, peraí, e para eu localizar essa VM diferente? Ah, muitas vezes eu tenho que ter um padrão como um Service Locator, como um Business Delegate para você fazer essa chamada. Então você começou a ver padrões também vindo do JVE, Front Controller, entre muitos outros. Você tem padrões, por exemplo, como os patterns of... Você pode dar só um zoom aí para poder enxergar um pouquinho melhor? Show de bola. Estou com a tela meio... Mais um, posso você conseguir? Mais um, claro, consigo sim. Aí, show. Beleza. Então, por exemplo, os patterns of Enterprise Application Architecture do Martin Fowler. Você vai ver muitosleza. Então, por exemplo, os Patterns of Enterprise Application Architecture, do Martin Fowler. Você vai ver muitos padrões como, por exemplo, Repository, sabe que é uma coisa que muita gente vê. Gateway. Padrões relacionados ao RM, Data Mappers. Padrões relacionados a moeda, Money. Você tem muitos padrões nesse livro também. E tantos outros livros, tantos outros autores, que também trazem variações de padrões que outros autores já viram. Como eu falei, os padrões do Gang of Four talvez sejam os mais conhecidos, e eles se dividem em três partes. Padrões de criação, padrões de estrutura e de comportamento. Então, dentro desses padrões, a gente vai ver muitos deles hoje, só para dar exemplos. Padrões de criação, as fábricas, os factories, abstract factory, factory method, padrões de estrutura, adapter, fade, decorator, proxy, padrões de comportamento, decorator, proxy, padrões de comportamento, você vai ter command, chain of responsibility, template method, strategy, states, iterator, mediator, observer, você vai ter vários padrões mais ligados a comportamento. Então, dentro da aula de hoje, a gente vai ver muitos desses padrões. De antemão, já recomendo obviamente esse livro aqui, que é o livro de padrões de projeto, mas também existe um outro livro que tem o mesmo nome, só que é de uma série chamada Head First. Head First. Está em Patrons também, mesmo nome, né? E que é uma série muito mais didática, que aborda de uma forma diferente, mais lúdica. Então, acho que pode ser bem interessante você estudar por meio desse livro. E o que eu tinha citado lá é o Patterns of Enterprise Application Architecture. Esse aqui é do Martin Fowler. Esse aqui, não me lembro se é da Katia Serra ou do Freeman, mas depois vocês podem dar uma olhada, além do próprio livro do Gengalfork, que é o principal. Beleza? Então, tá bom. O que eu imaginei para a nossa aula hoje? Tudo que eu me proponho a ensinar, eu sempre tento trazer uma visão muito prática, não tanto teórica, como eu falei. Eu programo no dia a dia e uso a maior parte dos padrões que eu vou mostrar aqui. Fazem parte do meu trabalho diário, praticamente. E para demonstrar, eu trouxe um exemplo bem interessante que eu acho que muita gente já deve ter passado, talvez, por isso, que é a emissão de nota fiscal. Emissão de nota fiscal hoje no Brasil, basicamente, ela se divide em notas fiscais de serviço e de produto, então tem uma diferença, a gente vai abordar de serviço, e dentro dessa nota de serviço existem formas de você reconhecer quanto você deve emitir de nota fiscal. Então, vou dar um exemplo. Se você tem um regime contábil de caixa, quer dizer que você reconhece o que você recebeu. Por isso que é caixa, né? É o que entrou na sua conta. Então, se alguém te pagou, você emite a nota. E existe um outro regime chamado de competência, que é conforme você entregou aquele serviço, você reconhece aquela receita. Entende? Isso independe de pagamento. A pessoa pode nem te pagar, mas você reconhece. E para dar um exemplo bem básico, se você faz faculdade, você tem uma mensalidade. Você geralmente divide isso em semestres, então você divide em seis semestres, em seis parcelas. E aí, supondo que você tenha uma mensalidade de mil reais. Você tem, então, geralmente, seis meses de aula, seis parcelas de mil. A conta fecha. O regime de caixa e competência, nesse caso, eles casam. Você vai ter uma nota por mês, você nem vai sentir. Agora, imagina que você paga a vista. Chega lá em janeiro, você paga os 6 mil reais de uma vez só. Olha agora a dúvida, né? E aí, você vai receber uma nota de 6 mil reais ou você vai seguir recebendo uma nota de mil por mês? A resposta está no regime. Se ele é de caixa, você recebe os 6 mil. Se ele é de competência, você vai receber uma nota de mil por mês. Então, é um pouco disso que a gente vai abordar, entender, desenvolver juntos e tentar chegar... Claro que é bem mais complexo que isso, quando você começa a atribuir desconto, quando você tem, muitas vezes, pagamentos que são renegociados. É mais complexo que isso, mas a gente vai implementar um cenário suficientemente interessante para que a gente aplique muitos desses padrões.