Padrões de Projeto Comportamentais

Apresentação em tema: "Padrões de Projeto Comportamentais"— Transcrição da apresentação:

1 Padrões de Projeto Comportamentais
Padrões de Projeto Orientados a Objetos II Profa. Danielle Martin Prof. Wolley W. Silva Universidade de Mogi das Cruzes

2 Padrão de Projeto Descrição da essência de uma solução comum apropriada a um problema conhecido e recorrente. Define boas práticas de programação. Facilita o reuso, flexibilidade e simplicidade do software. Deve ser suficientemente abstrato para ser reutilizado em diferentes aplicações.

3 23 Padrões de projeto – Gang of Four (GoF)
Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos Gang of four: Erich Gamma Richard Helm Ralph Johnson John Vlissides Publicado em Referência no assunto de design patterns.

4 Classificação dos padrões GoF
Criacionais De criação: Dizem respeito à criação de objetos. Estruturais De estrutura: Tratam da composição de classes e objetos. Comportamentais Do comportamento: Tratam da colaboração (interação e responsabilidade) entre classes e objetos.

5 Classificação dos padrões GoF
Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

6 Classificação dos padrões GoF
Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

7 PADRÃO STRATEGY

8 O problema Imagine um cenário de um sistema para lojas que deve permitir a execução das as seguintes regras para os pagamentos e descontos para suas vendas. Formas de pagamento A vista - Aplica-se um desconto proporcional ao valor da venda. Acima de 300, % de desconto Acima de 500, % de desconto A prazo - Deve ser acrescido 8% de juros sobre o valor da venda.

9 Solucao? Problemas: O método faz uso intensivo de if's e else's para testar opções de pagamento e tomar o fluxo correto. Sinais de um código pouco coeso. Para modificar qualquer regra de pagamento, deve-se primeiro encontrar a condicional entre muitas opções, o que pode gerar erros e quebrar o código que já esta funcionando. Para adicionar uma nova regra de pagamento, deve-se implementar uma nova condicional, o que pode tornar este código cada vez mais complexo.

10 Solucao: Padrao Strategy
Para melhorar o código anterior, podemos isolar o elemento da classe Venda que varia, a regra para o calculo de descontos ou acréscimo de juros, em sua própria hierarquia de classe conforme o diagrama apresentado a seguir:

11 Solucao: padrao Strategy
O padrao Strategy tem como objetivo central o encapsulamento de algoritmos que podem variar com facilidade para prover um comportamento mais adequado para um objeto de acordo com um contexto. Aspectos positivos O algoritmo poder ser alterado sem a modificação da classe Venda. A partir dessa estrutura, novas implementações podem ser criadas e introduzidas posteriormente. A lógica condicional na classe Venda foi reduzida. Como a escolha do algoritmo está na implementação do objeto que está compondo a classe, isso elimina a necessidade de ter condicionais para selecionar a lógica a ser executada. A implementação pode ser trocada em tempo de execução, assim o comportamento da classe é alterado dinamicamente, uma aplicação de polimorfismo. Aspectos negativos O aumento da complexidade na criação do objeto, pois a instância da dependência precisa ser criada e configurada. Caso o atributo seja nulo, a classe pode apresentar um comportamento inesperado. O aumento do número de classes. Há uma para cada algoritmo, podendo criar uma maior dificuldade em seu gerenciamento

12 Classes Regras de Pagamento

13 Classe Venda

14 Classe Aplicacao

15 Exercício Strategy: Implemente as classes abaixo

16 PADRÃO COMMAND

17 O problema Frequentemente, ao desenvolver aplicacoes web usando Servlets, nos deparamos com uma servlet de controle assim:

18 O problema Esta resolução é considerada um Anti-Pattern, pois no lugar de modelarmos uma classe por comando temos todas as lógicas agrupadas em uma só classe. O acréscimo de funcionalidades, tais como: Consultar e Excluir, implicará na construção de vários outro IF-else, tornando a modelagem menos flexível em termos de reuso / extensão e manutenção de código.

19 A solucao: padrao Command
O padrao Command recomenda o uso de um objeto para representar uma solicitacao, permitindo o encapsulamento de sua implementacao fisica. Cada acao da controle seria encapsulada em uma classe distinta, todas com a implementacao de uma interface comum.

20 Command + Factory Para desacoplar ainda mais o cliente que requisite a solicitacao da classe que a implementa, pode-se usar o padrao Factory em conjunto com o Command. Dessa forma, apenas uma Servlet e necessaria em toda a aplicacao e ela assume a responsabilidade de redirecionar as solicitacoes `as classes corretas.

21 Classes Command

22 Classe ControllerFactory

23 Executando o commando Ao acionar um comando com uma requisicao HTTP, seja GET ou POST, a nossa ControllerFactory ira localizar a classe apropriada e redirecionar o resultado para a pagina indicada pela classe de commando.

24 Exercício: Utilize o projeto de exemplo para completar a implementação

25 PADRÃO TEMPLATE METHOD

26 O problema Existem classes que montam e exportam relatórios para dois tipos de relatórios: financeiros e de horas de projeto. O algoritmo para montar relatórios é sempre o mesmo consistindo nas seguintes operações: montar o cabeçalho montar o corpo montar o rodapé

27 O problema Os detalhes da geração de cada relatório podem variar, por isso a criação de classes filhas. Porém, relatórios para o mesmo departamento podem manter o cabeçalho e o rodapé e variar o conteúdo do corpo. Em outros cenários pode ser necessário variar também o cabeçalho e o rodapé. A única coisa que continua constante é a estrutura e sequência do algoritmo. É possível fazer o reuso do algoritmo nessas situações?

28 A solução: padrão template
O padrão template method resolve casos em que parte de um determinado algoritmo depende da implementação de classes filhas, mas a estrutura do algoritmo é única. Características: 1. Definimos uma classe abstrata com métodos abstratos e métodos concretos 2. Nos métodos concretos da classe abstrata, definimos a estrutura dos algoritmos, chamando seus métodos abstratos, mesmo sem saber qual será a implementação. 3. Definimos sub-classes que implementam os métodos abstratos.

29 A solução: padrão template
O método montarRelatorio é o método template, que define quais métodos e em que ordem devem ser chamados para se montar um relatório, ainda que a implementação dos métodos abstrados ainda seja desconhecida.

30 Classe Relatorio Método template

31 Outro exemplo Reaproveitando mesmo cabeçalho e rodapé para todos os tipos de relatórios financeiros:

32 Classes RelatorioFinanceiro

33 Classe aplicação

34 PADRÃO STATE

35 O problema Um objeto pode passar por vários estados ao longo de seu ciclo de vida. O diagrama de estados da UML nos ajuda a identificar e representar esses estados e suas transições. O seguinte diagrama, por exemplo, representa os estados da matrícula de um aluno em uma disciplina. Como implementar esse controle dos estados da matrícula em nossas classes?

36 Solução 1? – atributos booleanos?
Apesar de parecer uma abordagem simples, usar vários atributos para gerenciar um estado dificulta o controle sobre o objeto: nada impede que em determinado momento, dois desses estados sejam setados para true ao mesmo tempo.

37 Solução 2? – atributo String
Utilizar um único atributo para armazenar o estado é uma maneira melhor de centralizar o controle. Porém, como impedir que existam objetos com status = “Cursando” e outros com status = “cursando" ou outras divergências na escrita da String que possam prejudicar o funcionamento correto do sistema? Ou ainda impedir que o objeto receba um estado que não foi planejado na aplicação?

38 Solução 3? – atributo int? Usar o atributo status do tipo int evita que um mesmo status possa ser escrito de formas diferentes. Mas como controlar qual número é associado a qual status? Seria necessário acrescentar um dicionário nos comentários do código e fazer a tradução toda vez que o status for exibido na aplicação. E como impedir que outros números sejam setados no status?

39 Solução 4 - Enum O enum é um tipo especial de dados que consiste num set de constantes pré definidas. Dessa forma, ao definir o tipo do atributo status como Situacao, garante-se que somente as constantes pré definidas do enum sejam valores válidos para esse atributo.

40 Solução 4 - Enum Vantagens:
1. Impossível setar o status para um valor que não esteja no enum 2. Usando o nome da constante, é impossível haver erros de digitação, pois o programa não compilaria 3. Novas constantes podem ser criadas no enum sem a necessidade de refatorar a classe Matricula.

41 Código Java com Enum

42 Código Java com Enum

43 O problema, parte 2 A utilização de enums é fortemente recomendada para monitorar status de objetos simples, definir tipos de objetos, ou até perfis de acesso de usuários. No entanto, algumas situações requerem um controle ainda mais forte sobre os estados de seus objetos, que é o caso onde cada estado desencadeia um comportamento diferente no objeto. Por exemplo, o que aconteceria se o programador tentasse trancar uma matrícula que já estivesse concluída? Ou aprovar um aluno cuja matrícula nunca foi confirmada? Para esses casos, existe uma alternativa que pode ser implementada, o padrão State.

44 Solução 5 – Padrão State Com o padrão State, cada estado do objeto será manipulado por uma classe diferente, todas implementam a mesma interface e sobrescrevem os mesmos comportamentos - estes que variam de acordo com o estado atual do objeto.

45 Solução 5 – Padrão State A classe Matricula, por sua vez, delega a execução de cada comportamento variável para o objeto status. Por exemplo, o método aprovar, no lugar de um código extenso repleto de “ifs”, teria apenas uma chamada para this.status.aprovar(); Dependendo do status atual do objeto, uma das sobrescritas da interface Situação seria acionada polimórficamente. Vantagens: 1) Maior controle sobre como cada estado se comporta em cada ação 2) Impossível esquecer de codificar um estado respondendo a um método, pois cada subclasse deve implementar todos os métodos da interface 3) É possível lançar a exceção IllegalStateException caso uma operação que não é permitida em determinado estado seja acionada

46 Codigo Java com State

47 Codigo Java com State

48 Codigo Java com State Os blocos de try/catch foram adicionados
ao código acima apenas para efeito de teste. Na aplicacao real, uma troca ilegal de estado deveria parar a execucao e notificar o usuario.

49 PADRÃO OBSERVER

50 O problema Uma ferramenta de compras online permite que o usuário solicite ser notificado quando surgir uma oferta para um produto de seu interesse. Podemos criar uma classe Interessado para armazenar os clientes interessados, mas como eles serão notificados no momento da alteração do produto? ?

51 A solução: padrão Observer
O padrão Observer: “Definir uma dependência um para muitos entre objetos, de maneira que quando um objeto muda de estado todos os seus dependentes são notificados e atualizados automaticamente”. A Oferta é o objeto observado e os Interessados são os observadores.

52 Observer no Java A biblioteca do Java possui uma implementação padrão do Observer, fornecendo a classe Observable e a interface Observer.

53 Classe Observadora

54 Classe Observada

55 Classes principais

56 Aplicação

57 PADRÃO CHAIN OF RESPONSIBILITY

58 Chain of Responsibility
Uma empresa precisa automatizar por meio de um software o atendimento ao cliente seguindo o padrão ITIL, Nível 1, Nível 2 e Nível 3;

59 Chain of Responsibility
Cria-se uma cadeia de classes com uma interface comum. Cada objeto dentro da cadeia possui um uma referência para o objeto da próxima classe. A requisição é entregue ao primeiro objeto da cadeia de receptores potenciais. Em ordem, os objetos da cadeia atendem à requisição e/ou a encaminham para o próximo objeto da fila até que a requisição seja atendida ou a fila acabe.

60 padrão Chain of Responsibility
Com o Chain of Responsibility temos seguinte benefícios e deficiências: Acoplamento reduzido: O padrão libera um objeto de ter que conhecer qual o outro objeto que trata de uma solicitação. Tanto o receptor como o remetente não têm conhecimento explicito um do outro, e um objeto que está na cadeia não necessita conhecer a estrutura da mesma. Flexibilidade adicional na atribuição de responsabilidades a objetos: É possível acrescentar ou mudar responsabilidades para tratamento de uma solicitação pelo acréscimo ou mudança da cadeia em tempo de execução. A recepção não é garantida: Uma vez que uma solicitação não tem um receptor explicito, não há garantia de que ela será tratada. A solicitação pode sair pelo final da cadeia sem ter sido tratada.

61 PADRÃO INTERPRETER

62 O problema Precisamos criar uma aplicação que resolva expressões numéricas que são entradas no formato String. Por exemplo: * (3 + 4) Como implementar esse algoritmo?

63 A solução: padrão interpreter
Pode-se quebrar a lógica de interpretação de uma expressão matemática em algumas etapas executadas sequencialmente: Interpretar parêntesis Interpretar multiplicação e divisão Interpretar adição e subtração A ideia do padrão interpreter é criar uma estrutura de classes para traduzir expressões com gramática complexa. Cada classe é responsável por interpretar parte ou termo da expressão e no final os resultados são combinados para trazer o resultado traduzido. Outro exemplo de uso: Compiladores

64 A solução: padrão interpreter
Classes interpretadoras:

65 Classes interpretadoras

66 Classe interpretadora
Obs: a primeira classe interpretadora (quem inicia a tradução) pode ser Considerada uma implementação do padrão facade, pois define as regras de como os demais interpretadores serão acionados.

67 Aplicação principal

68 Interpretadores adicionais

69 PADRÃO ITERATOR

70 O problema Existem várias classes de collections do java com diferentes algoritmos de armazenamento e busca. Ex: ArrayList, Vector, HashSet, PriorityQueue, LinkedList, Stack. É necessário criar uma interface comum a todas elas que permita a iteração por todos os elementos da lista, seja percorrendo uma lista ordenada, uma estrutura de árvore, etc. É possível?

71 A solução: padrão Iterator
O padrão Iterator cria uma interface comum a classes cuja função é percorrer uma estrutura de dados. Vantagens: Desacopla a forma de percorrer a estrutura da forma de armazenamento dos dados Permite percorrer uma estrutura de várias forma diferentes. Ex: percorrer uma árvore bintária em pré-ordem, in-ordem ou pós-ordem

72 Exemplo Iterator

73 Classes Iteradoras

74 Classe Aplicação

75 PADRÃO MEMENTO

76 O problema Em uma aplicação que permite a edição de desenhos e documentos de texto, precisa-se implementar a ação desfazer, que cancela a última modificação feita no sistema e retorna o objeto modificado ao seu estado original antes da modificação. Como implementar um algoritmo que armazene e restaure objetos de classes diferentes com formatos diferentes?

77 A solução: padrão Memento
A classe Memento permite armazenar o estado atual de um objeto, por exemplo em formato String. O padrão memento define objetos que podem criar mementos e ser restaurados a partir de um memento existente.

78 Classe Memento

79 Restauráveis

80 Restauráveis

81 Classe RestauradorHistorico

82 Classe Aplicacao

83 PADRÃO VISITOR

84 O problema Uma fábrica de produção armazena três tipos de dados de produtos de acordo com o estágio de produção em que se encontram: Produto matéria prima, Produto em produção, e Produto em estoque. Existem dois tipos de relatórios que podem ser gerados para cada tipo de produto: Relatório em PDF, e Relatório em XLS.

85 O problema Como podemos relacionar cada tipo de produto com os diferentes tipos de relatórios de forma dinâmica e sem dependências (um produto não deve ter um tipo de relatório fixo)?

86 A solução: padrão Visitor
O padrão Visitor permite que um objeto de uma hierarquia visite um objeto de outra hierarquia para realizar uma tarefa sobre o mesmo.

87 A solução: padrão Visitor
O termo “visitar” se dá pois o acoplamento entre os objetos é mínimo: ao contrário do padrão Bridge, no Visitor não há composição e nem dependência, apenas uma associação temporária entre ambos. Pode-se combinar o padrão Visitor com o Factory ou Singleton, para gerenciar a vida das classes de relatorio. Pode-se usar o Visitor para facilitar a comunicação entre classes que implementam estrturas de dados, como a Composite ou Interpreter.

88 Classes Relatorio

89 Classes Produto

90 Classe aplicação

91 PADRÃO MEDIATOR

92 O problema Um sistema de tradução automática de texto permite a tradução de mensagens entre vários idiomas diferentes. Quanto mais idiomas a ferramenta disponibilizar, maior a quantidade de combinações possíveis de traduções. Como implementar todas essas trocas de mensagens de forma fácil?

93 A solução: padrão mediator
Implementa-se uma classe mediator, que funciona como um mediador de relacionamentos muitos para muitos. Assim, permite-se fazer a tradução de qualquer idioma para qualquer idioma suportado, sem que estes se conheçam diretamente.

94 Classes idiomas

95 Classe Mediator

96 Classe principal

97 Classe principal