Design Patterns Quais padrões ainda sobrevivem com as novas tecnologias?

1. Design PatternsQuais 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 Direciona Solução Benefícios Consequências Padrões Relacionados

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 Classificação Sugerida Comportamento Criação Estrutura

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. Problema -> <- Solução Intercepting Filter

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