[MÚSICA] [MÚSICA] Olá a todos! Esse é o curso de Desenvolvimento Ágil com Padrões Projeto, eu sou Eduardo Guerra e hoje nós vamos falar o padrão "Observer". Padrão também muito utilizado, eu pessoalmente utilizo bastante e ele utiliza esse conceito de composição, só que ao invés de compor o ele compõe com vários objetos. Vamos ver como isso funciona. A ideia do "Observer" é ter uma estrutura que objetos possam receber notificações sobre alteração de outro objeto. Vamos ver que situação a gente usa e como isso aí funciona. Então, eu trouxe esse padrão para exemplificar para vocês que quando a gente utiliza a composição, tanto no "State" quanto no "Strategy", a gente compõe com único objeto, só que a gente pode compor com uma lista de objetos e esse é o caso do "Observer". Vamos ver como isso aí funciona, como sempre a gente vai começar com exemplo. Imagina aqui que eu tenha ali carrinho de compras, site de compras, e no momento que eu adiciono aquela característica no carrinho, várias coisas tem que acontecer, como por exemplo, relacionar o meu produto com outros produtos que também estão no carrinho, para eu saber que tipo de coisas que as pessoas costumam comprar junto. Eu tenho que ir lá e fazer uma reserva no meu estoque para que não ocorra de, por exemplo, o cara que adicionou o carrinho, na hora que for fechar a compra, aquele produto já tenha acabado. Eu tenho que ir lá, por exemplo, lá no meu subsistema de perfil de usuário e falar: "Olha, o cara adicionou o CD do fulano, o cara colocou o livro do sicrano". Para saber quais são os gostos dessa pessoa, e de repente poder sugerir para ela novos produtos relacionados. Então olha só, a minha classe carrinho, ela acaba sendo acoplada com vários subsistemas dentro do meu software, com o subsistema de estoque, com o subsistema de usuário, com o subsistema que trata desse relacionamento de produtos. Olha aí! Imagina o carrinho ter essa responsabilidade de chamar isso tudo. Imagina agora, por exemplo, que o meu carrinho tenha que chamar o subsistema para fazer uma estimativa de entrega. Nossa senhora! Olha a cara do sujeito sofrendo para ter que implementar isso já no meio daquele monte de coisas? Modificar o carrinho com esse montão de subsistemas acoplados vai ser complicado. Às vezes para adicionar alguma coisa, acaba atrapalhando outra, esse monte de dependências, às vezes, quase tudo que eu preciso fazer vai, quatro subsistemas e uma alteração vai acabar afetando o carrinho, então isso vai ser bem ruim, ter uma estrutura desse tipo. Bom, o quê que a gente pode fazer então? Uma ideia é o seguinte, e se ao invés de fazer todo mundo ir lá, o carrinho ir e chamar todo mundo, ao invés do carrinho ser o responsável por chamar todo mundo. E se eu permitisse que outras classes observassem o meu carrinho? Que elas pudessem receber, por exemplo, toda vez que adiciona produto, essas classes seriam avisadas, toda vez que alguém removeu algum produto, essas classes também seriam avisadas. Ao invés do carrinho precisar ele controlar isso tudo, vamos ver como seria isso isso dai. Então, o carrinho ele teria ali uma lista de observadores, e esse observador, por exemplo, ele poderia ir pelos métodos que, onde ele vai estar recebendo aquelas notificações do carrinho, aqueles eventos relacionados ao carrinho, como por exemplo produto adicionado ou produto que foi removido. E no meu carrinho, eu vou ter que adicionar métodos para poder tanto adicionar como remover esses observadores do carrinho. Então, como a gente viu que são vários sistemas, não faz sentido eu compor o meu carrinho com observador só, porque ai eu resolver problema, mas eu quero compor com vários, ou seja, eu quero aprender a avisar todos aqueles de tudo que está acontecendo. Eu vou sair aqui para vocês poderem ver melhor no diagrama. Então, a gente vê aqui que a gente pode ter implementações desse observador para fazer, por exemplo, a reserva do estoque, para fazer associação de produto, para atualizar o perfil de usuário. Então, a responsabilidade de ter essa funcionalidade relacionada ao carrinho, deixaria de ser da própria classe "Carrinho" e passaria para o próprio subsistema que deveria implementar o observador para receber do carrinho as informações que são pertinentes a ele. E aí, por exemplo, como que seria essa classe "Carrinho"? Ele teria a lista de observadores com os métodos "Adicione o Observador" e "Remover observador" para poder gerenciar quais são os objetos que estão escutando essas alterações, certo? E eu teria ali na, por exemplo, quando eu adicionasse produto, eu teria que percorrer aquela lista de observadores para informa los que o produto foi adicionado. A mesma coisa para informar que o produto foi removido. Olha que legal. Então, o carrinho agora, ele é acoplado somente a essa interface 'Observador", que faz parte da própria "API" de carrinho. E aí cada subsistema que vai ter que implementar essa interface e prover a implementação para reagir àqueles eventos gerados pelo carrinho. Olha ali que tem olhinho lá, que o carrinho chama o observador mas ele não sabe de que subsistema é aquele observador. E aí, por exemplo, veja como fica fácil agora, eu tinha levantado essa questão no começo da aula, se eu precisava criar uma nova funcionalidade para fazer essa estimativa de entrega. No momento que produto fosse adicionado ou removido, ativaria aquela funcionalidade ali, e ele estaria atualizando a estimativa de entrega de acordo com o que estivesse no carrinho. Então, é fácil criar novos observadores e incluir sem ter que lidar com aquele mundo de coisas, Certo? Bom, então esse foi o padrão observer. Fiquem ligados na próxima aula que tem resumão bem legal mostrando Observer na prática e continue assistindo o curso. Espero você na próxima aula. [MÚSICA] [MÚSICA]
