[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra, esse é o curso Desenvolvimento Ágil com Padrões de Projeto. Hoje vamos falar aqui dos elementos dos padrões. Na última aula, a gente viu o padrão strategy, nosso primeiro padrão. Só que a gente viu só pedacinho dele. Vamos hoje entender o que mais padrão tem, que outros elementos padrão possui e vamos usar o nosso strategy como exemplo para entender pouquinho o que é realmente, o que tem ali padrão. Então, erro muito comum que as pessoas têm é achar que padrão é só o diagrama dele. Não é. Inclusive, a gente vai encontrar, se a gente pegar vários padrões, durante o curso a gente vai falar pouquinho sobre isso, tem vários padrões que o diagrama é muito parecido, que a estrutura é muita parecida. Então, o que diferencia eles? É porque eles têm vários outros elementos. Eles têm contexto, eles têm problema que eles resolvem, eles têm a solução que eles estão propondo que envolve, sim, a estrutura do diagrama, mas não é só isso. Ele tem uma aplicabilidade, ou seja, situações que você deve utilizar ele, ele tem as consequências que, podem ser positivas ou negativas. Não é porque é uma solução boa que só vai ter consequência positiva, afinal, na nossa vida tudo é trade-off, tudo é balanço que você tem que fazer entre ter alguma coisa, sempre vai trazer uma coisa boa e outras coisas ruins. Certo? Então, o que seria o contexto? É a situação onde o problema ocorre. Por exemplo, se eu falar assim: Correr faz bem para a saúde. Depende do contexto. Se eu tenho, por exemplo, problema no joelho, nesse meu contexto, correr não vai fazer bem para a saúde, muito pelo contrário. Agora, de repente, se eu tenho problema de obesidade e preciso fazer mais exercício físico, aí talvez correr, dentro desse contexto, realmente faça bem para a saúde. Então, não adianta simplesmente jogar uma solução porque, se ela não for aplicada no contexto correto, pode ser desastre, pode ser pior ainda. Então, por isso que o padrão tem contexto, ele tem lugar ali, tipo de situação que ele vai ser aplicável. No caso aqui do nosso amigo strategy, o que acontece? A gente tem uma parte ali do comportamento que vai variar de acordo com algum fator. A gente tem algoritmo que tem pedaço que pode variar, que é justamente onde a gente vai estar aplicando o strategy. A gente tem o problema, que é: O que o nosso padrão está tentando resolver dentro daquele contexto. Então, no caso aqui, o que o strategy tenta fazer? Ele tenta encapsular uma família de algoritmos de forma que eu consiga trocar o algoritmo que é utilizado, que esse algoritmo seja intercambiável. Então, esse é o meu problema. Baseado no fato de que eu tenho esse problema, de como eu faço para poder trocar esses algoritmos, eu tenho a solução, que é o que eu estou propondo. Essa solução não é só o que fazer, mas como fazer e porque isso daí resolve o problema. O padrão ele não é só uma solução que você usa ali cego, é uma solução que é importante. Como ele não é pedaço de código que você simplesmente vai estar utilizando, é importante você entender os porquês do padrão, para você poder julgar que naquele caso ali é vantajoso você aplicar. Diferentemente de pedaço de código ou de componente que, às vezes, você pode usar sem nem saber o que está ali dentro, como eu falei nas aulas passadas que a gente comenta sobre o encapsulamento, o padrão não, o padrão você tem que ter essa compreensão, porque ele é uma solução de design de código. Então, no caso aqui do padrão strategy, o que seria a solução? A gente criar ali uma interface que vai representar, vai abstrair aquela parte do código que varia e compor a classe que precisa variar aquele pedacinho com essa interface. E aí, ter diversas implementações dessa interface com os diferentes algoritmos que eu quero poder intercambiar, que eu quero poder utilizar naquela classe principal. Aplicabilidade. Aplicabilidade são aquelas situações que o uso do padrão é adequado. No caso do strategy, que eu tenho, por exemplo, classes que são similares e muda somente pedaço do comportamento, você fala: Opa, podia ser uma classe só e eu compor ela com uma interface que vai dar aquela parte do comportamento que varia. Se eu tenho, por exemplo, algoritmo que pode ser trocado tempo de execução, no caso do strategy fica fácil, é só eu trocar a classe que está compondo. Então, ele é adequado para essa situação. Às vezes, também, quando eu tenho monte de condicionais, como era o nosso caso do estacionamento, eu posso substituir esse monte de condicionais com o strategy que eu vou estar colocando ali de acordo com a situação, às vezes até o parâmetro que eu utilizava ali para saber qual comportamento executar ali dentro da condicional. Baseado nisso, eu vou simplesmente colocar a instância do strategy dentro da classe. Então, a minha aplicabilidade são essas classes e são essas situações que a aplicação do padrão é adequada. E aí tem as consequências. Como eu falei no começo dessa aula, nada só traz benefícios. Sempre vai ter uma coisa boa e uma coisa ruim. Se eu estou fazendo lá e falo: Mas eu posso fazer isso que eu, digamos assim, não vai fazer mal. Mas se não faz bem e você está gastando tempo, já te traz uma consequência negativa, que é você estar gastando tempo com uma solução que não está te trazendo benefício. Então sempre existe trade-off. Sempre existe essa troca. Ou seja, você sempre quando utiliza uma solução, você ganha alguma coisa e você perde outra. No caso aqui do strategy, a gente viu lá no exemplo do estacionamento que, comparado com outras alternativas de solução, evitou que eu tivesse uma certa duplicação de código. Olhando também pelo código inicial do estacionamento, a gente viu que a gente removeu todos aqueles condicionais, além do fato de permitir a mudança ali da classe que está compondo tempo de execução. Então, essas são consequências positivas do meu padrão, por outro lado, eu vou ter monte de classes sendo criadas. Antes eu tinha uma só, agora eu vou ter que gerenciar várias classes. Ou seja, imagina se eu tiver dez tipos de tarifas de estacionamento diferentes, eu vou ter dez classes para representar isso. Talvez seja melhor do que monte de if? Sim, mas mesmo assim, eu vou ter que gerenciar aquele monte de classes, o que também seria uma consequência ruim de usar essa solução. Outra coisa, introduz complexidade. Você está tirando uma coisa de uma classe, está deixando uma invocação indireta. Obviamente, talvez seja custo pequeno para a solução que a gente chegou. Mas imagina só, por exemplo, se eu tiver uma classe só? Não vale a pena. A ideia é justamente poder trocar, mas se eu tiver uma classe só, eu estou adicionando uma complexidade que é desnecessária. Então, tudo isso a gente tem que pesar e lembrar que padrão nem sempre vai ser a melhor solução. A gente tem que avaliar o contexto, avaliar se ele é aplicável naquele caso, ver as consequências positivas e negativas que caso pode pesar mais e outro caso pode pesar menos. Por exemplo, às vezes eu estou falando evitar duplicação, pode ser que determinado caso a duplicação, os casos são tão diferentes, que a duplicação não era relevante. Então esse fator positivo vai pesar pouco. Por outro lado, eu posso ter caso que, ao invés de três ou quatro classes, eu vou ter 50 comportamentos diferentes. Então, essa questão de aumentar a quantidade de classes vai ser muito mais relevante. Então, tudo depende do seu contexto, tudo depende de você pesar as vantagens e desvantagens e ver se naquele caso o seu padrão deve ser aplicado ou não. Então, o que acontece, a questão que eu introduzi aqui no começo da aula, falando que o padrão não é só o diagrama, é que muitos padrões têm a estrutura parecida, pegando aí o nosso amigo do camelo e o dromedário. São animais diferentes. Por mais que você olhe assim: É a mesma coisa, é parecido. Não é, é bem diferente. Então, mesma coisa. Apesar de ter alguns padrões que você olha o diagrama deles e é meio parecido, eles podem ser aplicados situações completamente diferentes, ter consequências diferentes, dentro, cada de seu contexto. Então não se apegue aos diagramas. Isso aí é erro bastante comum quando a gente aprende o padrão, de enxergar o padrão só como aquele diagrama. Então, tome cuidado com isso e lembre que o padrão tem muito mais coisa além do diagrama dele. Certo? Então, nessa aula, a gente viu os elementos dos padrões. Espero que a partir disso tenha sido possível compreender melhor o que é padrão. Certo? Muito obrigado, espero vocês na próxima aula. [MÚSICA] [MÚSICA]
