Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, graças às boas práticas e princípios exercitados nos cursos anteriores; mas você talvez não se sinta ainda confortável em lidar com cenários mais complexos, onde é difícil desenvolver software com código de qualidade com flexibilidade suficiente para facilitar a implementação de mudanças repentinas de requisitos. O objetivo deste curso é oferecer a você um aprofundamento em técnicas de programação orientadas a objetos pelo uso de padrões de projeto no contexto de desenvolvimento ágil. Os seguintes conceitos são apresentados neste curso: • Revisão de conceitos de orientação a objetos: abstração de dados, encapsulamento, herança e polimorfismo • Reúso por meio de herança: padrões Null Object, Template Method e Factory Method • Delegando comportamento com composição: padrões Strategy, Bridge, State e Observer • Composição recursiva: padrões Composite e Chain of Responsibility • Envolvendo objetos: padrões Proxy, Decorator e Adapter • Estratégias para criar objetos: padrões Static Fabric Methods, Singleton e Builder • Modularidade: padrão Dependency Injection Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar partes da aplicação Web final com o componente de gamificação enriquecido constantes do Trabalho de Conclusão da Especialização, aplicando onde apropriado alguns dos padrões apresentados neste curso durante a refatoração na prática TDD.
Padrão Observer
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
Desenvolvimento Ágil com Padrões de Projeto
40 ratings
Na lição
Semana 2
Olá, bem-vindo ao Curso 5 – Desenvolvimento Ágil com Padrões de Projeto! Neste módulo você aprenderá a identificar quatro padrões em que se utiliza a herança; depois, três padrões em que se utiliza a composição.
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
