[MÚSICA] [MÚSICA] Olá todos, meu nome é Eduardo Guerra. Esse é o curso de Desenvolvimento Ágil com Padrões de Projetos. Hoje eu vou falar pouquinho mais para vocês sobre os padrões, mas dos padrões de uma forma geral. Nas aulas passadas a gente pegou exemplo, identificou alí uma solução, depois a gente viu como generalizar essa solução. Depois a gente identificou vários elementos para esse padrão, mas até então a gente está trabalhando num único padrão. Agora eu queria falar para você pouquinho mais sobre os padrões geral. O que que é interessante nessa ideia dos padrões. O que é que é a vantagem? O que que a gente ganha aprendendo padrões. Quais são essas características dos padrões que fazem eles serem uma coisa que apareceu na programação por volta de 1994 e, até hoje, é uma habilidade, é conhecimento essencial para os desenvolvedores. Então, a primeira questão é que o padrão ele não é pedaço de código. Eu falei isso ainda nas aulas e faço questão de ressaltar de novo. Muita gente fala assim "Vamos reutilizar alguma coisa" já pensa pegar pedacinho de código, dar Ctrl+C, Ctrl+V, ou pegar alí componente colocar como uma biblioteca e reutilizar, mas o padrão não é nada disso. O padrão é uma solução. Ele não vai, você pega o padrão e coloca no seu código. O padrão ele vem na sua cabeça. Ele é uma ideia que ele vai ser inserido na sua cabeça. A partir do momento que você entender esse padrão, você vai passar a inserir a ideia dele no seu código. E aí isso quer dizer que o padrão nem sempre vai ser exatamente igual. Por isso que ele não é código. Se ele fosse exatamente igual, eu poderia criar código, implemento aquilo [INCOMPREENSÍVEL] Mas não, ele cada vez é diferente. Então, por isso que ele tem que ser ideia, porque eu tenho que ver como que eu vou adequar ele cada uma das situações. Bom, uma outra vantagem dos padrões é que eu vou estar ensinando para você padrão que não é uma coisa aqui que o Guerra aprendeu, não é uma coisa aqui que o Guerra inventou. Vou falar " fiz aqui padrão". Não é alguma coisa que alguém pegou e falou "Olha, está aqui" "Usa" Não. Ele veio da experiencia. Ou seja, foram vários sistemas que foram utilizando aquele tipo de solução e aí alguém olhou e falou "Olha, espera aí, essas soluções usadas nesses vários sistemas'' ''elas têm uma coisa comum". Então o pessoal abstraiu aquela ideia e documentou aquela prática como padrão. Então, o padrão por definição, ele é uma solução que já é provada. Ele já foi utilizado vários contextos. Não quer dizer que toda vez que eu usar padrão eu vou estar usando da forma correta. Porque eu posso pegar padrão que ele é feito para determinado contexto e usar ele outro contexto. No contexto errado não vai dar certo. Então, não quer dizer que sempre que eu usar o padrão vai estar sempre certo. Não. Eu não posso sair usando o padrão cegamente. Justamente por isso que o padrão não é só o diagrama. Ele tem lá contexto, tem aplicabilidade para eu saber quando usar. Por isso que eu tenho que ter na minha cabeça, para entender como ele tem que ser utilizado. Mais uma coisa que é importante nos padrões é isso, ele é uma solução provável. Ele não é uma solução que alguém apareceu e que ninguém encontrou. Não quer dizer o fato de uma prática ser utilizada vários sistemas que ela automaticamente vira padrão. O padrão, quando a gente olha na mãozinha, tem que ser uma boa prática. A gente pode ter, até tem algumas pessoas que chamam de anti-pattern, que são más práticas que são utilizadas de forma recorrente sistemas. Mas não é isso, os padrões eles sempre documentam boas práticas. Isso também, como eu falei, tem que estar atento no contexto para saber aplicar ele no momento correto. Então, a gente tem que estar de olho nas consequências, tem que estar de olho na aplicabilidade, para não pegar uma coisa que é uma boa prática contexto e aplicar num contexto que aquilo não vai ser legal. Mas o padrão não é só ser uma solução recorrente. Tem que ser uma boa solução recorrente. Uma outra característica muito, muito interessante nos padrões é que ele cria vocabulário de design. Isso facilita muito a comunicação dentro de uma equipe. que as pessoas conhecem esse padrão. Então, para vocês que assistiram as primeiras aulas eu tenho certeza que já estão dominando aí o padrão strategy, de repente se alguém chegar para vocês e falar assim "Você pode criar strategy para resolver esse problema"; na sua cabeça já vai vir a solução, já vai vir o contexto, já vai vir as consequências. Toda aquela carga de informação contida no padrão strategy, aquilo já vai vir dentro da sua cabeça para você considerar e utilizar aí. Imagina se não existisse esse nome e a pessoa tivesse que detalhar para você todo o padrão para explicar o que você tinha que fazer. Então, é muito mais fácil falar "usa strategy", assim como outros padrões que a gente vai ver durante o curso. Usa adapter, usa proxy usa composite. Então, é interessante a gente poder ter nomes que representam essas soluções. Se elas são soluções recorrentes, inclusive, por exemplo, se eu utilizo o nome de padrão numa classe dentro do meu sistema, por exemplo, cálculo strategy, a pessoa vai [INCOMPREENSÍVEL] naquela interface, naquela classe, vai olhar e falar assim, olha aqui a gente está implementando o padrão strategy. E aí a pessoa já vai ter uma compreensão melhor do que você está tentando, do que motivou você a utilizar aquela solução naquela parte do código. Então, com isso eu acho que deu para entender pouquinho mais o que são os padrões, essas vantagens de estar aprendendo sobre eles e utilizando os padrões. Certo? Eu costumo dizer que o padrão, se a gente, digamos assim a gente for comparar, a gente escrever código com a gente estar escrevendo, por exemplo texto; Eu diria que os padrões eles são aquelas coisas do tipo " quando você escreve texto argumentativo, você começa introduzindo a questão, você apresenta os argumentos tem determinados tipos de argumento". Então, todo esse formato que a gente aprende, " texto narrativo" tem tais coisas". São justamente esses padrões, são essas formas de você fazer a coisa. Então, digamos assim, você aprender a escrever uma frase, uma palavra, não vai fazer você escrever bom texto. Da mesma forma que você aprender herança, você aprender partes alí, como fazer coisas da linguagem não vai fazer bom software. Da mesma forma que você tem que botar as frases juntas na hora que você vai escrever texto, você também tem que saber coordenar aquelas features da linguagem, aquelas coisas, uma interface, uma classe, quais métodos você vai criar para criar o seu software. Então, o padrão ele te dá soluções para questões que você tem vários softwares. Eu acho o padrão conhecimento essencial, hoje dia, para os desenvolvedores. Certo? Por isso dou tanta ênfase nessa questão. Certo? Então, muito obrigado. Espero que vocês estejam motivados para o resto do curso, e aproveitem os outros padrões. Muito obrigado. [MÚSICA] [MÚSICA]
