Padrões de projeto - Adapter, Proxy, Composite e Bridge

14.132 visualizações

Publicada em

Apresentação sobre Padrões de Projeto para desenvolvimento OO, abordando os padrões:
Adapter
Proxy
Composite
Bridge

Apresentado para avaliação da matéria de Engenharia de Software II da Universidade de Vila Velha.

Alunos: Lorran Pegoretti e Luiz Marcon
Truma: CC5M

Universidade de VIia Velha.

0 comentários
6 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
14.132
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
421
Comentários
0
Gostaram
6
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Padrões de projeto - Adapter, Proxy, Composite e Bridge

  1. 1. UNIVERSIDADE VILA VELHALORRAN PEGORETTI, LUIZ MARCONTRABALHO REALIZADO PARA AVALIAÇÃO NA DISCIPLINA DE ENGENHARIA DE SOFTWARE II, DOCURSO DE CIÊNCIA DA COMPUTAÇÃO, TURNO MATUTINO, DA UNIVERSIDADE DE VILA VELHA(UVV), MINISTRADA PELO PROFESSOR CRISTIANO BIANCARDI.2013Padrões de Projeto1
  2. 2. Tópicos abordados Padrão de Projeto Adapter Proxy Composite Bridge Conclusões Referências2
  3. 3. Padrão de Projeto3
  4. 4. Padrão de Projeto Um padrão é um conjunto de informações instrutivas que possui umnome e que capta a estrutura essencial e o raciocínio de uma famíliade soluções comprovadamente bem sucedidas para um problemarepetido que ocorre sob um determinado contexto e um conjunto derepercussões Um Padrão de Projeto de Software (Design Pattern) descreve umasolução para um problema que ocorre com frequência durante odesenvolvimento de software, podendo ser considerado como um par“problema/solução” Um Padrão de Projeto de Software não é um código final, é umadescrição ou modelo de como resolver o problema do qual trata, quepode ser usada em muitas situações diferentes.4
  5. 5. Padrão de Projeto Um padrão de projeto define Nome Todo padrão deve ter um nome significativo. Pode ser uma única palavra oufrase curta que se refira ao padrão e ao conhecimento ou estrutura descritospor ele. Se o padrão possuir mais do que um nome comumente usado oureconhecível na literatura, subseções “Aliases” ou “Also know as” devem sercriadas Problema Estabelece o problema a ser resolvido pelo padrão, descreve a intenção eobjetivos do padrão perante o contexto e forças específicas Solução Relacionamentos estáticos e regras dinâmicas descrevendo como obter oresultado desejado. Equivale a dar instruções que descrevem como o problemaé resolvido, podendo para isso utilizar texto, diagramas e figuras5
  6. 6. Padrão de Projeto Um padrão de projeto define Contexto (Quando aplicar a solução) Pré-condições dentro das quais o problema e sua solução costumam ocorrer epara as quais a solução é desejável, o que reflete a aplicabilidade do padrão.Pode também ser considerado como a configuração inicial do sistema antes daaplicação do padrão Resultado O estado ou configuração do sistema após a aplicação do padrão, ou seja, as“consequências” (tanto boas quanto ruins). Descreve as pós-condições e efeitoscolaterais do padrão6
  7. 7. Padrão de Projeto Visam facilitar a reutilização de soluções de desenho, isto é, soluçõesna fase de projeto do software Estabelecem um vocabulário comum de desenho, facilitandocomunicação, documentação e aprendizado dos sistemasde software7
  8. 8. Padrão de Projeto Classificação Quanto ao Escopo Classes Objetos Quanto ao seu propósito Criacional Comportamental Estrutural Diz respeito a composição de objetos e classes. Exemplos: Adapter Bridge Composite Decorator Facade Flyweight Proxy8
  9. 9. Adapter9
  10. 10. Adapter A intenção do Padrão Adapter é converter a interface deuma classe para uma outra que os clientes esperam. OAdapter permite que classes com interfaces incompatíveispassem a trabalhar em conjunto Basicamente, isso quer dizer que precisamos de umamaneira de criar uma nova interface para um objeto quefunciona, mas que possui uma interface “errada”10
  11. 11. Adapter O padrão Adapter é muito utilizado quando precisamosencaixar uma nova biblioteca de classes, adquirida de umfornecedor, em um sistema de software já existente, porémessas bibliotecas de classe do novo fornecedor são diferentesdas bibliotecas de classes do fornecedor antigo A definição oficial do padrão Adapter: “O Padrão Adapterconverte uma interface de uma classe para outra interface queo cliente espera encontrar. O Adaptador permite que classescom interfaces incompatíveis trabalhem juntas” O adaptador converte UMA interface paraoutra, porém, também poderíamos ter um caso em queprecisaríamos adaptar mais de uma classe, nesse caso entra emcena outro padrão de projeto, o Facade11
  12. 12. AdapterDiagrama de classe do Padrão AdapterFonte: http://www.devmedia.com.br/padrao-de-projeto-adapter-em-java/2646712
  13. 13. Adapter Exemplo - Código13
  14. 14. ‹#›
  15. 15. Adapter Comparação Adapter e FacadeFacade Adapter ComentárioAs classe já existem? Sim Sim Já tenho classes em ambosExiste uma interface quedevemos projetar?Não Sim No facade, eu não preciso projetar uma interface comono Adapter.Um objeto precisa tercomportamentopolimórfico?Não Provável Não estou interessado no comportamento polimórficono Facade, enquanto que em Adapter provavelmenteestou.É necessário que sejauma interface simples?Sim Não No caso do padrão Facade, a motivação é simplificar ainterface. Com o Adapter, eu estou tentando projetaruma interface existente e não posso simplificar ascoisas, mesmo que seja possível simplificá-la.Tabela 1 - Comparação padrão Facade com padrão Adapter.15
  16. 16. Proxy16
  17. 17. Proxy O objetivo principal é encapsular um objeto através de um outroobjeto que possui a mesma interface, de forma que o segundoobjeto, conhecido como “Proxy”, controla o acesso aoprimeiro, que é o objeto real.17
  18. 18. Proxy - Vantagens Permite deixar transparente o local (endereço) do objeto real. Ocliente não precisa conhecer se o objeto é remoto ou não, estetipo de proxy é conhecido como Remote Proxy. Útil para realizar otimizações, como cache de objetos. Tambémpode ser implementado rotinas de logs e controle de acesso(segurança). Este tipo de proxy é conhecido como Virtual Proxy18
  19. 19. Proxy - DiagramaDiagrama de classes geral Padrão de Projeto Proxy19
  20. 20. Proxy – Exemplo de uso O framework Hibernate também utiliza o pattern Proxy, porexemplo ao fazer o “lazy-loading”, técnica utilizado para acessar obanco de dados apenas quando for necessário. Muitas vezesquando trabalhamos com o Hibernate, e uma busca érealizada, por exemplo usando o método “session.load(id)”, umProxy para o objeto real é retornado. Neste caso o objeto aindanão está completamente preenchido, pois nenhum SQL foirealizado até este momento. Apenas quando uma propriedadedeste objeto (métodos getX) ou um relacionamento, como porexemplo “empresa.getFuncionarios()” forem chamados, a consultano banco será realizada. Tudo isto de forma transparente para ocliente.20
  21. 21. Composite21
  22. 22. Composite A intenção do Composite é compor objetos em estruturas deárvore para representar hierarquias parte-todo O Composite permite aos clientes tratarem de maneirauniforme objetos individuais e objetos compostos Em certas estruturas necessitamos por muitas vezes demétodos e funções que já estão especificadas em umdeterminado objeto, sendo necessário apenas a ligaçãoentre os dois para assim poder ser reutilizado o código Tratar composições e unidades uniformemente22
  23. 23. Composite Exemplo de aplicação Aplicações gráficas, tais como editores de desenhopermitem aos usuários construir diagramas complexos apartir de componentes simples O usuário pode agrupar componentes para formarcomponentes ainda maiores, os quais, por suavez, podem ser agrupados para formar componentesainda maiores Uma implementação simples poderia definir classespara primitivas gráficas, como Texto e Linhas, além deoutras classes que funcionam como recipientes(conteiners) para estas primitivas23
  24. 24. Composite Exemplo de aplicaçãoGráficoLinha Retângulo TextoContainerDiagrama de classe Composite24
  25. 25. Composite Exemplo de aplicação Há um problema com esta abordagem O código que usa estas classes deve tratar objetos primitivose objetos recipientes de modo diferente, mesmo se namaior parte do tempo o usuário os trate de forma idêntica O padrão Composite descreve como usar acomposição de maneira recursiva tal que os clientesnão tenham que fazer esta distinção25
  26. 26. Composite Exemplo de aplicaçãoDiagrama de classe CompositeLinhaDesenhar()Retangulo Texto FotoDesenhar()Add(g : Grafico)Remover(g : Grafico)GetFilho(c : int)GraficoDesenhar()graficosparaTodos g em graficosg.Desenhar()add g a lista degraficosClienteDesenhar() Desenhar()26
  27. 27. Composite Exemplo de aplicação27
  28. 28. Composite Exemplo de aplicação28
  29. 29. Composite Exemplo de aplicação29
  30. 30. Composite Exemplo de aplicação O resultado da execução desse programa seráLinhaRetânguloTexto30
  31. 31. Composite Estrutura geral do padrão CompositeDiagrama de classes geral Padrão de Projeto Composite31
  32. 32. Composite Estrutura geral do padrão Composite Participantes Componente Declara a interface para objetos na composição Implementa comportamento default para interface comum a todas asclasses, como apropriado Declara uma interface para acessar ou gerenciar seus componentes filhos Folha Representa objetos folhas na composição Uma folha não tem filhos Define comportamento para objetos primitivos na composição32
  33. 33. Composite Estrutura geral do padrão Composite Participantes Composição Define comportamento para Componentes que têm filhos Armazena Componentes filhos Implementa operações relacionadas com filhos na interface doComponente Cliente Manipula objetos na composição através da interface Componente33
  34. 34. Composite Estrutura geral do padrão Composite Consequências Com o uso do padrão Composite podemos criar objetos comuma grande complexidade e eles serem compostos poroutros objetos menores, além de deixar o código bemestruturado e de fácil entendimento, sendo rápida a forma deadicionar novos componentes, métodos e funções34
  35. 35. Bridge35
  36. 36. Bridge A intenção do Padrão de Projeto Bridge édesacoplar uma abstração de suaimplementação, de forma que as duas possamvariar independentemente De novo A intenção do Padrão de projeto Bridge édesacoplar uma abstração de sua implementaçãode tal forma que a implementação possa serfacilmente trocada Como? Encapsulando os detalhes de implementação emum objeto que é um componente da abstração36
  37. 37. Bridge - Exemplo Considere a construção de um módulo para desenhar figuras Considere que há duas classes externas de desenho a seremutilizadas: DP1 e DP2 Primeira versão: “somente retângulos devem ser desenhados” Retângulos são definidos com dois pares de pontosSolução:DP1 DP2Usado para desenharretângulosdraw_a_line(x1, y1, x2, y2) drawline(x1, x2, y1, y2)Usado para desenharcírculosdraw_a_circle(x, y, r) drawcircle(x, y, r)Tabela 2 – Comparação classes de desenho37
  38. 38. Bridge - ExemploDiagrama de classes solução exemplo Padrão de Projeto Bridge38
  39. 39. Bridge - Exemplo Suponha agora, o seguintes novos requisitos “As classes externas agora desenham círculos.Portanto, nosso módulo de desenho deve tambémter a possibilidade de desenhar círculos” “Além disso, o cliente do nosso módulo de desenhonão precisa saber a diferença entre um retângulo eum círculo.” Solução Criamos uma classe abstrata Shape, e fazemos com queela seja superclasse tanto de Rectangle quanto de Circle O cliente agora se comunica com objetos Shape Sendo assim, temos uma nova solução39
  40. 40. Bridge - ExemploDiagrama de classes nova solução exemplo Padrão de Projeto Bridge40
  41. 41. Bridge - Exemplo Infelizmente, esta abordagem traznovos problemas. Observe a 3ª linhado diagrama de classes As classes da linha representam quatrotipos específicos de Shapes E se eu tiver um outro programa dedesenho? Seis tipos diferentes de Shapes (duasárvores de programas) E se eu tiver um outro tipo de Shape, outra variação de conceito? Terei nove tipos diferentes de Shapes (para os três programas dedesenho)41
  42. 42. Bridge - Exemplo A explosão de classes surge porque, nesta solução, aabstração (os tipos de Shape) e a implementação (osprogramas de desenho) estão fortemente acoplados. Cada tipo de figura (abstração) deve saber que tipode módulo externo (implementação) ele deve utilizar Precisamos de um modo de desacoplar as variações naabstração das variações na implementação, de tal formaque o número de classes cresça somente linearmente42
  43. 43. Bridge - Exemplo Esta é exatamente a intenção do padrão Bridge Desacoplar a abstração de sua implementação, de modoque possam variar independentementeAbstração 1Abstração 2Abstração 3...Implementação AImplementação BImplementação C...43
  44. 44. Bridge - Exemplo Neste projeto, Shape usa Drawing para manifestar seucomportamento, chegamos ao padrão BridgeDiagrama de classes nova solução exemplo Padrão de Projeto Bridge, com padrão aplicado44
  45. 45. Bridge Estrutura básicaDiagrama de classes estrutura básica Padrão de Projeto Bridge45
  46. 46. Bridge – Exemplo aplicação Exemplo Look and Feel – Java Swing Objetos JFrame, JButton, etc. possuem um componente internoque é construído com um “look and feel” particular No entanto, clientes (programadores) somente precisam interagircom JFrame, Jbutton, etcWindowsLookAndFeel DefaultLookAndFeel46
  47. 47. Bridge – Exemplo aplicação Exemplo abstração driver específico do banco de dados47
  48. 48. Bridge Aplicabilidade O padrão Bridge é útil quando se tem uma abstração que temdiferentes implementações Este padrão permite que a abstração e a sua implementaçãovariem independentemente O projeto e a implementação são mais robustos e mais flexíveis àsmudanças futuras quando se usa o padrão48
  49. 49. Conclusões 49
  50. 50. Referências50
  51. 51. Referências Padrões e Frameworks de Software - http://www2.icmc.usp.br/~rtvb/apostila.pdf Padrão de Projeto Adapter em Java - http://www.devmedia.com.br/padrao-de-projeto-adapter-em-java/26467 Padrões de projeto proxy - http://www2.lccv.ufal.br/Members/psycho/a-day-in-life/padroes-de-projeto-proxy Padrão de Projeto – Composite -http://padroesdeprojetodesoftware.blogspot.com.br/2012/06/nome-e-classificacao-do-padrao.html Padrões de Projeto - http://www.cin.ufpe.br/~if718/transparencias/pdf/05-padroesGoF.pdf Pattern Proxy - http://www.devmedia.com.br/pattern-proxy/4066#ixzz2Tsfmdiih Padrões de Projeto -http://www.inf.ufsc.br/~bosco/extensao/NovosTalentos2012/D:/additional/addnlApps/jhtp6_appM_design_patterns.pdf Módulo III Padrões GOF: Bridge – (Professores: Eduardo Bezerra, Isamel H F Santos –PUC-RIO) http://www.tecgraf.puc-rio.br/~ismael/Cursos/XJavaPadroes/aulas/3-PadroesGOF/JavaPadroes_3-PadroesGOF-Bridge.pdf51
  52. 52. Obrigado!52

×