Design Patterns

3.358 visualizações

Publicada em

The Developers Conference (Floripa 2008)
Globalcode / VOffice
Design Patterns

Publicada em: Tecnologia, Diversão e humor
0 comentários
7 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
3.358
No SlideShare
0
A partir de incorporações
0
Número de incorporações
30
Ações
Compartilhamentos
0
Downloads
178
Comentários
0
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Design Patterns

  1. 1. Design Patterns Quais padrões ainda sobrevivem com as novas tecnologias? Rodrigo Cândido da Silva Instrutor VOffice / Globalcode
  2. 2. Objetivo <ul><li>Realizar uma introdução sobre padrões de projetos e demonstrar alguns padrões existentes no catálogo GoF e Core J2EE. </li></ul>
  3. 3. Agenda <ul><li>Introdução </li></ul><ul><li>GoF Patterns </li></ul><ul><li>Core J2EE Patterns </li></ul><ul><li>Conclusões </li></ul><ul><li>Perguntas e Respostas </li></ul>
  4. 4. Introdução <ul><li>Design pattern é... </li></ul><ul><ul><li>Uma forma padrão de organizar classes e objetos; </li></ul></ul><ul><ul><li>Nomes para soluções que você já modelou; </li></ul></ul><ul><ul><li>Uma forma de compartilhar conhecimentos sobre POO; </li></ul></ul><ul><ul><li>Soluções POO para problemas que incidem em diversos cenários de desenvolvimento; </li></ul></ul><ul><ul><li>Uma definição de conjunto finito de responsabilidades para uma classe; </li></ul></ul>
  5. 5. Introdução <ul><li>Ao adotar design-patterns... </li></ul><ul><ul><li>Seu código fica mais organizado; </li></ul></ul><ul><ul><li>Aumenta a qualidade; </li></ul></ul><ul><ul><li>Diminui a complexidade; </li></ul></ul><ul><ul><li>Facilita a comunicação dentro da equipe; </li></ul></ul><ul><ul><li>Facilita a ambientação de novos membros na equipe; </li></ul></ul><ul><ul><li>Aprende com a experiência dos outros. </li></ul></ul>
  6. 6. Como surgem padrões? Problema Contextualização Solução Benefícios Padrões Relacionados Consequências Direciona
  7. 7. Como documentá-los? <ul><li>Elementos de um padrão... </li></ul><ul><ul><li>Nome </li></ul></ul><ul><ul><li>Problema </li></ul></ul><ul><ul><ul><li>Quando aplicar o padrão, em quais condições? </li></ul></ul></ul><ul><ul><li>Solução </li></ul></ul><ul><ul><ul><li>Como usar os recursos disponíveis (classes e objetos) para solucionar o problema contextualizado. </li></ul></ul></ul><ul><ul><li>Benefícios </li></ul></ul><ul><ul><li>Conseqüências </li></ul></ul><ul><ul><ul><li>Custos de utilização </li></ul></ul></ul><ul><ul><ul><li>Impactos na flexibilidade, portabilidade, performance, etc. </li></ul></ul></ul><ul><ul><li>Padrões relacionados </li></ul></ul>
  8. 8. Família de Padrões <ul><li>Existem algumas famílias conhecidas de padrões... </li></ul><ul><ul><li>GoF (Gang of Four) </li></ul></ul><ul><ul><li>Core J2EE Patterns </li></ul></ul><ul><ul><li>GRASP </li></ul></ul><ul><ul><li>POSA </li></ul></ul><ul><ul><li>Enterprise Integration Patterns </li></ul></ul><ul><ul><li>SOA Patterns </li></ul></ul><ul><ul><li>etc. </li></ul></ul>
  9. 9. GoF Patterns <ul><li>Surgiram em 1995 com a publicação do livro “Design Patterns: Elements of Reusable Object-Oriented Software”; </li></ul><ul><li>Devido ao livro possuir 4 autores, este catálogo de padrões ficou popularmente conhecimento como GoF (Gang of Four); </li></ul><ul><li>Define uma lista com 23 padrões de projeto; </li></ul><ul><li>A publicação deste livro é considerado um marco na evolução e utilização de padrões de projetos dentro dos processos de desenvolvimento de software. </li></ul>
  10. 10. GoF Patterns Comportamento Criação Estrutura Classificação Sugerida
  11. 11. Abstract Factory <ul><li>Prover uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Promover o desacoplamento entre classes da aplicação; </li></ul></ul><ul><ul><li>Abstrair a lógica de criação e inicialização dos objetos; </li></ul></ul><ul><ul><li>Tornar facilitada a possível troca entre famílias de objetos. </li></ul></ul>
  12. 12. Abstract Factory
  13. 13. Singleton <ul><li>Garantir para que uma determinada classe do sistema terá somente um número determinado de instâncias (objeto) criadas, provendo um ponto de acesso global a mesma. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Controlar o acesso as instâncias da classe; </li></ul></ul><ul><ul><li>Reduzir a utilização desnecessária de memória; </li></ul></ul><ul><ul><li>Fornecer mais flexibilidade que a utilização de estruturas estáticas; </li></ul></ul><ul><ul><li>Habilita ter subclasses. </li></ul></ul>
  14. 14. Singleton
  15. 15. Prototype <ul><li>Criar tipo de objetos diferentes, usando como base um protótipo (instância de um objeto com estrutura semelhante). </li></ul>
  16. 16. Prototype Problema Solução
  17. 17. Mediator <ul><li>Definir um objeto que encapsula o modelo como um conjunto de objetos interagem entre si, promovendo o fraco acoplamento. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Desacoplar os diversos participantes; </li></ul></ul><ul><ul><li>Eliminar relacionamentos N-to-N; </li></ul></ul><ul><ul><li>Centralizar o controle; </li></ul></ul><ul><ul><li>Facilitar inclusão de novos participantes. </li></ul></ul>
  18. 18. Mediator Problema Solução
  19. 19. Adapter <ul><li>Converter a interface de uma classe em outra interface esperada pelo cliente. Atuar como um intermediário entre duas classes, convertendo a interface de uma para que a mesma possa ser utilizada pela outra. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Permitir dois objetos incompatíveis se comunicar e interagir; </li></ul></ul><ul><ul><li>Elevar a reusabilidade de sistemas antigos. </li></ul></ul>
  20. 20. Adapter
  21. 21. Proxy <ul><li>Prover um objeto substituto para interceptar e controlar o acesso a um outro objeto. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Esconder complexidades relacionadas com o acesso ao objeto destino (acesso remoto); </li></ul></ul><ul><ul><li>Transparência para o cliente; </li></ul></ul><ul><ul><li>Permitir maior eficiência com caching no cliente </li></ul></ul>
  22. 22. Proxy <ul><li>Exemplo </li></ul><ul><ul><li>Stubs e Skeletons do Java RMI. </li></ul></ul>
  23. 23. Flyweight <ul><li>Utilizar o mecanismo de compartilhamento de instâncias para suportar uma alto número de objetos na aplicação de maneira eficiente. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Reduzir número de objetos a serem tratados pela aplicação; </li></ul></ul><ul><ul><li>Reduzir utilização de memória; </li></ul></ul>
  24. 24. Flyweight <ul><li>Problema </li></ul><ul><li>Solução </li></ul>
  25. 25. Flyweight Exemplo Implementação Usando Caching
  26. 26. Template Method <ul><li>Definir o esqueleto de um algoritmo dentro de uma operação em uma classe, deixando alguns passos a serem preenchidos pelas subclasses. </li></ul>
  27. 27. Template Method
  28. 28. Template Method
  29. 29. Core J2EE Patterns <ul><li>Surgiu com a publicação do livro Core J2EE Patterns em 2001; </li></ul><ul><li>Descreve um catálogo de 25 padrões específicos para plataforma Java EE; </li></ul><ul><li>Produto de anos de experiência aplicados em consultoria em projetos Java EE, documentados por consultores da Sun Microsystems. </li></ul><ul><li>Atualmente este livro encontra-se publicado em segunda edição, com alguns “novos” design patterns; </li></ul>
  30. 30. Core J2EE Patterns <ul><li>Os padrões encontram-se sub-divididos em três categorias: </li></ul><ul><ul><li>Apresentação </li></ul></ul><ul><ul><li>Negócio </li></ul></ul><ul><ul><li>Integração </li></ul></ul>
  31. 31. Intercepting Filter <ul><li>Permitir o pré e/ou pós processamento de uma requisição para um determinado componente, possibilitando a facilidade na configuração de ativação e desativação deste processamento. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Centralizar controle; </li></ul></ul><ul><ul><li>Promover a reusabilidade; </li></ul></ul><ul><ul><li>Fornecer flexibilidade através de configurações declarativas; </li></ul></ul>
  32. 32. Intercepting Filter <ul><li>Problema -> </li></ul><ul><li><- Solução </li></ul>
  33. 33. Front Controller <ul><li>Centralizar o processamento de requisições em uma único e centralizado componente. Redirecionar o processamento após sua finalização, para a view respectiva. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Controle centralizado; </li></ul></ul><ul><ul><li>Melhorar gerenciamento de segurança; </li></ul></ul><ul><ul><li>Promover reuso; </li></ul></ul>
  34. 34. Front Controller Problema -> <- Solução
  35. 35. View Helper <ul><li>Separar do código as responsabilidades de formatação da interface do usuário, do processamento de dados necessário à construção da view. </li></ul>
  36. 36. View Helper <ul><li>Problema </li></ul><ul><li>Solução </li></ul>
  37. 37. Composite View <ul><li>Componentizar a view para a partir de views menores dividir as responsabilidades, simplificar a construção da interface e promover o reuso. </li></ul>
  38. 38. Composite View Problema -> <- Solução
  39. 39. Business Delegate <ul><li>Esconder dos clientes detalhes acerca da camada de negócios, fornecendo uma interface de serviços semelhantes aos serviços de negócio. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Reduzir acoplamento; </li></ul></ul><ul><ul><li>Traduzir exceções dos serviços de negócio; </li></ul></ul><ul><ul><li>Expor interfaces mais simples; </li></ul></ul><ul><ul><li>Poder melhorar performance utilizando estratégias de cache; </li></ul></ul><ul><ul><li>Implementar recuperação à falhas; </li></ul></ul><ul><ul><li>Ocultar o fato dos objetos de negócio estarem remotos. </li></ul></ul>
  40. 40. Business Delegate Problema -> <- Solução
  41. 41. Service Locator <ul><li>Esconder dos clientes a necessidade do conhecimento dos serviços de localização (JNDI) e da lógica necessária para utilização do mesmo, fornecendo uma interface simplificada para recuperar os componentes remotos. </li></ul>
  42. 42. Service Locator <ul><li>Problema </li></ul><ul><li>Solução </li></ul>
  43. 43. Session Facade <ul><li>Simplificar a interface do cliente dos componentes de negócio e controlar o acesso e a lógica de negócio entre os componentes existentes. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Introduzir uma camada controladora; </li></ul></ul><ul><ul><li>Expor uma interface uniforme; </li></ul></ul><ul><ul><li>Reduzir o acoplamento do cliente; </li></ul></ul><ul><ul><li>Melhorar a performance </li></ul></ul><ul><ul><li>Centralizar o controle de segurança e transações; </li></ul></ul><ul><ul><li>Reduzir a interface visível para o cliente. </li></ul></ul>
  44. 44. Session Facade <ul><li>Problema </li></ul><ul><li>Solução </li></ul>
  45. 45. Business Object <ul><li>Separar dados de negócio da lógica usando um modelo de objetos. Abstrair os dados de negócio da aplicação, representando uma entidade. </li></ul>
  46. 46. Business Object Problema -> <- Solução
  47. 47. Transfer Object <ul><li>Reduzir a quantidade de requisições necessárias para recuperar um objeto. Encapsular um subconjunto de dados a ser utilizado pelo cliente, afim de retorná-los em somente uma requisição remota. </li></ul>
  48. 48. Transfer Object Problema -> <- Solução
  49. 49. Data Access Object <ul><li>Abstrair e encapsular todo o acesso a uma fonte de dados, separando-a do código de negócio e visualização da aplicação. </li></ul>
  50. 50. Data Access Object Problema -> <- Solução
  51. 51. Service Activator <ul><li>Receber requisições e mensagens assíncronas do cliente. Localizar e chamar os métodos de negócio para atender as requisições de forma assíncrona. </li></ul>
  52. 52. Service Activator Problema -> <- Solução
  53. 53. Domain Store <ul><li>Oferecer um mecanismo transparente para persistência dos objetos de negócio. Abstrair o repositório de dados do cliente, afim de fornecer um mecanismo de persistência automático. </li></ul><ul><li>Benefícios </li></ul><ul><ul><li>Separar modelo de objetos de negócio da lógica de persistência; </li></ul></ul><ul><ul><li>Melhorar testabilidade da camada de persistência; </li></ul></ul>
  54. 54. Domain Store Problema -> <- Solução
  55. 55. Outros Design Patterns...
  56. 56. Conclusões <ul><li>Será que alguns padrões de projetos morreram com a evolução das novas tecnologias? </li></ul><ul><li>Devo realmente utilizar padrões de projetos na minha aplicação? </li></ul><ul><li>Qual será o futuro dos padrões de projetos? Terão eles um fim? </li></ul>
  57. 57. Perguntas e Respostas <ul><li>? </li></ul>

×