Design Patterns Quais padr

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
Intercepting Filter

• Problema -gt

• lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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 -gt
lt- 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

• ?