[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra, esse é o curso de Desenvolvimento Ágil com Padrões de Projeto e nessa aula a gente vai falar sobre o seu primeiro padrão, o primeiro padrão que você vai aprender. Na aula passada a gente falou de problema, né? Problema lá do estacionamento, como a gente conseguiu resolver. Agora, como é que isso aí vai virar padrão? Então, voltando pouquinho lá na solução final que a gente chegou. A gente criou ali uma classe, na verdade, uma interface, essa interface cálculo, onde eu posso criar implementações que têm estratégias de cálculo diferentes para calcular o valor do estacionamento. E aí surgiu. Eu achei muito interessante essa solução de eu criar essa abstração e compor a minha classe principal com ela. Será que eu consigo utilizar isso outros casos? Então, pensando aqui eu lembrei, por exemplo, de problema que eu tinha outro sistema para calcular imposto para estados diferentes. Aqui no Brasil, por exemplo, a gente tem uma legislação estadual que pode diferenciar como imposto é calculado de estado para o outro. Então, se eu tenho sistema que precisa atuar no Brasil inteiro, ele tem que ter essa flexibilidade. E aí eu paro e penso: Olha, que legal! Eu posso pegar aquela classe que eu usei lá no estacionamento para diferentes tipos de estacionamento, de acordo com o tamanho da estadia ou o tipo do veículo, eu posso criar classes ali com diferentes abordagens para o cálculo de imposto. Já é mais caso que eu consigo aproveitar aquela mesma estrutura da solução. Olha, caso aqui completamente diferente que eu acho que, de repente, eu consigo fazer isso também é, por exemplo: Eu tenho software que utiliza mapas e no momento que eu vou lá e clico cima de objeto que está sendo identificado ali naquele mapa, eu tenho tipos de comportamentos diferentes. Então, ao invés de usar herança, por exemplo, nesses objetos que às vezes são objetos completamente diferentes, mas que tem comportamento parecido. Por exemplo, que eu clico e vai dar zoom, outro clico e vai buscar informações da base de dados, outro eu clico e ele vai selecionar e assim por diante. Esse comportamento de clicar eu posso também utilizar uma classe que, por exemplo, vai implementar uma interface, no momento que eu clicar ele vai chamar o método dessa classe. Vou voltar aqui para vocês verem, igualzinho essa estrutura ali. No caso ali do imposto, o cálculo do imposto estaria no lugar daquele cálculo ali. Esse caso do imposto, se a gente for parar para pensar, é até bem parecido. Mas se a gente for parar para pensar no caso do mapa, no lugar ali da classe que faz o cálculo, eu teria uma classe que implementa uma ação, o que já é completamente diferente. Por exemplo, a ação de clique num determinado objeto. Então, a gente vê que é uma solução, é uma ideia boa que a gente teve na hora de fazer o design que a gente consegue utilizar outros casos. Então, isso é que é padrão de projeto. Padrão de projeto não é código, não é componente, ele é o quê? Ele é uma solução. Ele é uma solução recorrente. O que significa ser recorrente? Ela já aconteceu e já foi utilizada vários lugares. Então é uma solução que a gente pode utilizar sabendo que é uma solução que já foi provada como boa, que pode ser utilizada para resolver problema similar diferentes contextos. Toda vez que eu tiver problema parecido com aquele problema do estacionamento, que eu tenho vários comportamentos que dependem de uma série de fatores, eu posso, por exemplo, delegar esse comportamento para uma outra classe que está compondo aquela minha classe principal e, dependendo da classe que eu utilizar ali para compor, vai ser acionado comportamento diferente naquele momento. Então, o que é padrão de projeto? Ele é uma solução. Uma solução já provada que você consegue usar diferentes sistemas. E isso que a gente viu é o nosso primeiro padrão, que é o padrão strategy. A gente tem ali essa estruturazinha, por mais que a gente vá ver na próxima aula que padrão não é só o diagrama, não são só as classes dele, ele tem vários outros elementos além disso. Se a gente tivesse que descrever essa estrutura que a gente identificou como padrão nessa aula de uma forma pouquinho mais geral, a gente tem ali uma classe principal, que tem método principal, e aí, algum momento, aquilo ali vai acionar algoritmo. Algoritmo que pode variar dependendo de alguma circunstância. Então eu tenho ali, por exemplo, uma interface ou uma classe abstrata que representa aquele algoritmo, certo? E eu vou ter, onde está ali o algoritmo concreto, vão ter implementações dessa interface, ou extensões dessa classe, que vão efetivamente implementar aquele comportamento que completa aquele método principal. Esse é o meu padrão strategy. Não sei se você lembra, algum momento, que eu até comentei: Eu tenho várias estratégias para calcular o valor do estacionamento. É por isso que ele chama strategy, que você consegue ter várias estratégias para poder colocar ali no lugar de uma determinada ação no seu sistema. Bom, é isso. Nessa aula vocês conheceram o primeiro padrão de vocês, o strategy. Espero que vocês fiquem com a gente aqui na próxima aula, onde a gente vai entrar pouquinho mais detalhes sobre quais os elementos que padrão tem. Certo? [MÚSICA] [MÚSICA]
