[MÚSICA] [MÚSICA] Olá a todos. Esse é o curso de desenvolvimento ágil com padrões de projetos. Meu nome é Eduardo Guerra e, nessa aula, eu vou mostrar exemplo para a gente entender aí o quê que é padrão. Tá? A gente vai ver exemplo que vai mostrar uma solução específica ali para problema e a gente vai começar a pensar como que a gente pode reaproveitar essa solução, outros casos, tá? Então, vamos ao exemplo. Então Imagina que você está fazendo lá "software" que existe, software de estacionamento e ele trabalha alí com diversos tipos de tarifa. Então se a gente olhar aí o código, por exemplo, que faz esse cálculo, ele tem ali, por exemplo, que o veículo é veículo de passeio, ele tem ali o cálculo por hora, ele tem o cálculo ali para quem paga por diária, ele tem o cálculo para os mensalistas. E se eu olhar ali ó, comentado ali, tem por exemplo, já seria uma outra regra de negócios, por exemplo, para veículos de carga, tá?! Agora imagine que esse "software" que você tem, que já tem esse monte de item aí, que só de olhar me dá certo calafrio, certo? Imagina que esse "software", ele era de uma empresa e passou a vendido para empresas que possuem outras lógicas, outros tipos de categorias de tarifação. E aí, como é que você vai fazer isso? Talvez, a gente olha para aquele código ali e fala assim: " vamos meter mais uns 'if´s' ali, né?" Mete "if", taca "if" ali. E aí vai ficar código monstruoso, muito difícil de dar manutenção, de repente com uma certa duplicação dentro de cada "if", precisaria mudar umas coisas, às vezes teria que mudar vários locais. Não daria muito certo. Então, de repente, o desenvolvedor lá pensou: "Hum! E se eu utilizasse herança para resolver esse problema?" Então vamos ver como é que ficaria,né?! Ele teria, por exemplo, ali o método para cada uma subclasse para cada empresa de estacionamento que tivesse uma lógica diferente e ele teria ali o cálculo do valor da compra, tá? Só que o problema é o seguinte, por mais que os estacionamentos sejam diferentes, eles ainda têm muita lógica comum. Então, por exemplo, às vezes o cálculo por hora de estacionamento, seja bem similar ao de outro. Por mais que não sejam todos iguais, sempre vai ter ali essa duplicação de código. Então, para cada empresa, no caso, que tivesse o meu sistema, eu teria que estar criando uma classe nova. Por mais que, por exemplo, aquilo ali fosse uma combinação das estratégias já utilizadas pelos estacionamentos. Então, essa duplicação de código seria uma desvantagem aí de estar a herança nesse caso. O quê que eu poderia fazer? Então, o desenvolvedor teve uma outra ideia: "E se eu tentasse compor a classe"? Então eu tenho a minha classe ali principal onde que faz aquele cálculo e se eu tentasse compô-la com uma classe que soubesse como fazer o cálculo naquele caso? Ou seja, eu teria algum outro lugar do sistema falando: "Olha! Esse é o estacionamento tal e e é o tipo de carro tal". Então a classe que tem que fazer o cálculo é a classe X. E aí, sempre que aquele tipo de regra se aplicar, eu posso estar colocando a classe X ali, de repente até, meio parametrizada. Teria alguma coisa assim, né? Eu teria ali, por exemplo, aquela interface ali, cálculo. E ela teria ali várias implementações, cada uma com tipo diferente ali de cálculo. Então, por exemplo, por hora simples, por hora com tolerância. E por aí vai. Então a gente pode estar compondo a classe de acordo com a tarifa, de acordo com o estacionamento, de acordo com o tipo de veículo. Então isso ai é interessante porque eu tiro da classe essa responsabilidade ai de saber qual que é o cálculo. Ou seja, algum lugar eu vou estar falando: " esse carro aqui se encaixa nessa, esse veículo se encaixa nesse tipo de tarifa". Aí eu vou lá e coloco a classe certa e ele simplesmente vai usar essa classe. Então agora se a gente olhar ali, por exemplo, ele simplesmente, eles calcularam a conta ali, vai simplesmente estar delegando para outra classe. Ai vai e fala ó: "Tem uma outra classe aqui que sabe fazer essa parte, eu simplesmente vou chamá-la ali e ela vai fazer o cálculo para mim". E a vantagem é, a classe, pegando exemplo ali do cálculo da diária, é assim ó, pequenininha, tá? Então, a gente tem ali alguma, vai ter ali algumas classes com as estratégias de cálculo diferentes. Nota-se, por exemplo, que é uma classe parametrizada que por mais que os estacionamentos tenham valores de diárias, por exemplo, diferentes, né? Eu posso parametrizar essa classe, então se eu tenho cálculo com diária, eu posso sempre estar utilizando essa classe independente de valor, ou seja, eu posso parametrizá-la. Coisa que a gente já conhece, essa questão da parametrização de classe, posso usar mesmo assim. Olha que bacana que ficou. Umas classes pequininhas, fáceis de dar manutenção e e eu vou sempre que aquele tipo de regra se aplicar, eu vou pegar e vou estar utilizando a mesma classe. E aí? Que legal! Aí o cara falou: "Nossa que bacana essa solução, né. Antes eu tinha monte de risco, pensei fazer herança, ia ter monte de duplicação. Agora eu tenho ali uma classe que chama método de outra, e essa outra ai tem várias implementações ali, relativamente pequenas, que eu simplesmente escolho a que é mais adequada e coloco lá". Olha que legal! Ai a pessoa: "Peraí, será que eu não consigo usar essa solução outros casos?; Será que ninguém nunca usou isso aí antes?" Ai eu vou pedir para você para essa pergunta, que a gente vai ver na próxima aula. Então, os padrões, eles têm pouco a ver com isso, e a gente esta pegando soluções que já deram certo outros sistemas, na verdade, vários outros lugares, vários contextos e a gente esta aplicando isso no nosso sistema. Então segura aí. Nessa aula, eu mostrei aí exemplo para a gente utilizar, para a gente entender pouquinho mais do que é o padrão. Só que a gente viu uma solução para problema específico. O quê que seria o padrão então? Aguardo vocês na próxima aula para a gente continuar esse raciocínio, muito obrigado. [MÚSICA] [MÚSICA]
