Design Patterns
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,882
On Slideshare
3,855
From Embeds
27
Number of Embeds
4

Actions

Shares
Downloads
159
Comments
0
Likes
3

Embeds 27

http://www.slideshare.net 21
http://www.linkedin.com 4
http://ig.gmodules.com 1
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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