Padrões de Projeto Estruturais

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

1 Padrões de Projeto Estruturais
Padrões de Projeto Orientados a Objetos Profa. Danielle Martin 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 FACADE

8 O problema Em um aplicativo social, cada vez que um usuário é banido, deve-se removê-lo da lista de amizades de seus amigos e apagar os posts já feitos pelo mesmo. Existem métodos prontos para realizer cada uma dessas tarefas nas classes de modelo existentes.

9 O problema O desenvolvedor colocou o seguinte codigo na camada de controle:

10 O problema Problemas: A responsabilidade de realizar regras de negócio nao deveria ser da camada de controle Há um grande acoplamento entre a classe UsuarioControle e outras classes que apenas serão necessárias para o caso de uso Banir usuario. Se houver a necessidade de executar a ação banir usuario em outro momento do sistema, o reuso será dificultado.

11 A solucao: padrao Facade
Cria-se uma classe UsuarioFacade que encapsula métodos de negocio complexos com chamadas para varios outros metodos e classes de negocios. Dessa forma, o UsuarioFacade torna-se uma interface mais simples para qualquer classe no Sistema que precise executar a ação banir usuario.

12 Aplicacao controle

13 UsuarioFacade

14 PADRÃO ADAPTER

15 O problema Uma loja de vendas utiliza objetos Funcionario para controle do pagamento de seus empregados. Os métodos calcularSalarioAnual e calcularSalarioMensal são sobrescritos pelas classes Gerente, Vendedor e Administrativo, devido a diferenças nas regras de cálculo de cada tipo de funcionário.

16 O problema Recentemente, a loja adquiriu uma de suas concorrentes e, ainda que as duas lojas irão operar isoladamente como lojas independentes, a gerência solicitou que ambos os sistemas sejam integrados para que a consulta de salários dos funcionários possa trazer informações de funcionários das duas lojas.

17 O problema No entanto, ao examinar a modelagem do sistema da loja 2, o analista encontrou a seguinte estrutura de classes: A interface Empregado do sistema da Loja 2 disponbiliza um método consultarSalario que recebe o período de consulta como parâmetro (mensal, trimestral ou anual). Este método pode ser utilizado para realizar a consulta desejada pela gerência, mas seu formato é diferente do sistema atual.

18 O problema Como podemos utilizar essas novas classes para integrá-las na aplicação original? ?

19 A solução Podemos criar uma classe Adaptadora, que irá funcionar como um intermediário entre as duas interfaces, adaptando o formato dos métodos da interface Funcionario para os métodos da interface Empregado. Esta é a ideia do padrão Adapter, que permite que uma classe criada com um formato diferente ou externo ao sistema atual possa ser utilizada com as interfaces existentes no mesmo, quase como um adaptador de tomadas do mundo real:

20 A solução Dessa forma, a nova modelagem do sistema ficaria assim:

21 A solução

22 A solução

23 Diferença entre Class Adapter e Object Adapter
Utiliza herança para relacionar o adaptador com o adaptado. Solução mais rígida, pois Java e C# não suportam herança múltipla. Object Adapter Utiliza composição para relacionar o adaptador com o adaptado. Solução mais flexível.

24 PADRÃO COMPOSITE

25 O problema Componentes de hardware podem ser combinados para formar uma peça de hardware, que por sua vez também é um componente e pode ser usado para compor um computador customizado.

26 Anti-padrão Cada composição de componente é modelada individualmente. A solução é complexa e pouco flexível.

27 Anti-padrão Código da classe Computador

28 A solução: padrão Composite
O padrão Composite propõe a composição recursiva para compor objetos de mesmo tipo, a fim de criar objetos compostos em uma estrutura tipo a de árvore.

29 A solução: padrão Composite
Todos os componentes herdam de uma superclasse comum. Componentes compostos (como computador, placa mãe e placa de vídeo) podem ser compostos por outros componentes.

30 Classes Componente e ComponenteComposite

31 Classes HardDisk e Computador
Objeto folha Objeto composite

32 Aplicacao cliente

33 PADRÃO BRIDGE

34 O problema Considere o seguinte diagrama das classes de um sistema bancário: Como podemos perceber, existe uma classe abstrata Conta que implementa alguns comportamentos concretos, como sacar, depositar e transferirParaConta. Existem também dois tipos de contas distintas, a ContaCorrente e a ContaPoupança, cada uma com suas particularidades: da conta corrente é cobrada uma tarifa mensal correspondente à uma cesta de serviços e a conta poupança permite a capitalização do dinheiro aplicado, sem nenhuma cobrança de tarifas.

35 O problema O que acontece, no entanto, quando o banco em questão decide criar um novo tipo de conta? Surge assim a ContaMista, uma conta corrente, com sua devida cesta de serviços, mas que também permite a capitalização. Como isso afetaria as classes do nosso sistema?

36 Solução 1? Como já temos uma abstração Conta, basta criar uma nova classe concreta ContaMista, com os comportamentos aplicáveis: Apesar de parecer a solução mais simples à primeira vista, reparem que a operação cobrarTarifa é implementada duas vezes, duplicada entre a a ContaCorrente e a ContaMista, e a operação capitalizar também está duplicada, entre a ContaPoupanca e a ContaMista.

37 Solução 2? Vamos tentar criar novas abstrações que também estendam o comportamento de Conta:

38 Uma classe pode ter apenas uma superclasse.
Solução 2? Quase lá! Mas o Java e outras linguagens não aceitam herança múltipla, como aparece no caso da ContaMista. Uma classe pode ter apenas uma superclasse. Mas se a ContaMista é uma ContaComTarifa e é também uma ContaComCapitalização, e não pode herdar ambas, como vamos resolver esse problema?

39 A solução – Padrão Bridge
Percebemos que há dois comportamentos distintos que se combinam de maneiras diferentes entre os vários tipos de conta. Vamos então usar nossos conhecimentos sobre abstrações de interfaces para isolar esses comportamentos em classes distintas e usar a composição para criar uma “ponte" entre a classe Conta e esses comportamentos. A ideia do Padrão Bridge é desacoplar duas ou mais hierarquias de comportamentos em abstrações diferentes e usar a composição para relacioná-las.

40 A solução – Padrão Bridge
Com essa implementação, podemos inclusive implementar novos tipos de tarifas e de capitalização no futuro, sem prejudicar nossa estrutura. Exemplo:

41 Classe Conta

42 Classes filhas

43 Classe principal

44 PADRÃO FLYWEIGHT

45 O problema Imagine uma aplicação que utiliza uma quantidade muito grande de objetos pequenos. Cada vez que uma funcionalidade é executada, novos objetos em grande quantidade são alocados na memória. Há um risco de haver estouro de memória.

46 O problema Exemplo: No desenvolvimento de um jogo, as imagens (sprites) dos elementos exibidos são carregadas e impressas na tela várias vezes. Cada vez que um objeto aparece ou se move na tela, precisamos carregar o objeto novamente ou é possível reusá-lo?

47 A solução: padrão Flyweight
O padrão Flyweight propõe a criação de uma Factory que armazena um pool de objetos compartilhados. Dessa forma, o mesmo objeto sprite pode ser utilizado toda vez que a mesma imagem for impressa na tela. Usar o flyweight quando: Há grande quantidade de objetos de granularidade fina Características intrínsecas dos objetos podem ser compartilhadas Não há necessidade da identidade do objeto ser exclusivo

48 A solução: padrão Flyweight
A SpriteFactory utiliza uma composição para armazenar os objetos SpriteFlyweight já criados, reutilizando-os quando solicitado.

49 Objetos Flyweight

50 SpriteFactory e Cenario

51 Aplicacao

52 PADRÃO PROXY

53 O problema Imagine um programa que permite ler e navegar pelo conteúdo de pastas de arquivos. Arquivos podem ser objetos grandes dependendo do seu conteúdo. Uma pasta pode ter milhares de arquivos. Ao listar todos os arquivos de uma pasta, iremos trazer uma coleção de milhares de objetos grandes?

54 A solução: padrão Proxy
O padrão proxy propõe a criação de um objeto substituto (proxy) que pode ser instanciado no lugar do objeto real. Enquanto o objeto real carrega todo o conteúdo do arquivo, o proxy só carrega o nome, ocupando menos memória. O proxy e o objeto real devem implementar a mesma interface

55 A solução: padrão Proxy
Dessa forma, quando uma listagem de arquivos da pasta for feita, basta retornarmos os arquivos proxy, que não carregam o conteúdo do arquivo a menos que o acesso ao objeto real seja solicitado.

56 Classes Arquivo e ArquivoReal

57 Class Pasta

58 Aplicação

59 Tipos de proxy Protection Proxy: controla acesso ao objeto real, por exemplo, verificando a devida permissão. Virtual Proxy: cria um objeto “mock”, mais leve, adiando a criação do objeto real. Remote Proxy: o objeto real tem uma localização remota. O proxy trabalha localmente e pode sincronizar o envio de dados ao objeto real.

60 Outro exemplo de Proxy O proxy pode herdar da classe a qual ele substitui, podendo assumir suas características quando necessário. Podemos criar um segundo proxy para arquivos com senha, por exemplo. Proxy do proxy

61 Outro exemplo de Proxy

62 Outro exemplo de Proxy

63 PADRÃO DECORATOR

64 O problema Uma empresa de treinamentos em tecnologia para ministrar seus cursos forma turmas de acordo com as seguintes categorias: Turma padrão: para cursos ministrados na sede da empresa com um calendário pré-definido Turma PJ: para cursos ministrados no formato de consultoria Turma Promocional: para cursos com valores promocionais

65 O problema Houve uma mudança da regra de negócio e agora, por uma estratégia comercial as turmas do tipo padrão e PJ, em alguns casos, também devem seguir a politica de uma turma promocional. Como resolver?

66 A solução: padrão Decorator
Cria-se uma classe Decorator, que tem o objetivo de preservar o objeto original e acrescentar algum comportamento adicional (neste caso, o desconto da promoção). O objeto original de cada turma permanece inalterado.

67 As classes Turma

68 As classes decorator

69 A aplicacao