O documento introduz os padrões de projetos GoF e Core J2EE, definindo o que são padrões de projeto e como surgem, e descrevendo alguns padrões específicos como Abstract Factory, Singleton, Template Method, Front Controller, Business Delegate e Domain Store. A conclusão questiona se alguns padrões ainda se aplicam com novas tecnologias.

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 ?