Design Patterns

1
Design Patterns

• A adoção dos padrões terá um efeito profundo e
  duradouro sobre a forma de escrevermos programas
• Ward Cunningham e Ralph Johnson

2
Design Patterns

• Conhecer os princípios OO não faz de você um bom
  projetista OO
• Bons projetos OO são reutilizáveis, extensíveis e
  fáceis de manter
• Os padrões mostram como construir um projeto OO
  com estas qualidades
• Os padrões mostram soluções OO comprovadamente
  eficientes

3
Design Patterns

• Os padrões não são uma biblioteca de código. Eles
  fornecem soluções genéricas para problemas de
  projeto. Você tem de aplicá-los a sua aplicação
  específica.
• Os padrões não são inventados, eles são
  descobertos
• A maioria dos padrões aborda questões relativas a
  proteção contra variações
• A maioria dos padrões permite que parte do
  sistema varie independentemente de todas as
  outras partes

4
Design Patterns

• Freqüentemente tentamos extrair e encapsular
  aquilo que varia em um sistema
• Os padrões fornecem uma linguagem compartilhada
  que permite maximizar o valor da sua comunicação
  com outros desenvolvedores

5
Design Patterns
6
O Adaptador
7
O Adaptador

• O Adaptador converte a interface de uma classe em
  uma outra interface esperada pelo cliente.
• O Adaptador permite que classes com interfaces
  incompatíveis trabalhem em conjunto o que, de
  outra forma, seria impossível

8
O Adaptador
9
O Adaptador
10
O Adaptador
11
O Adaptador
12
O código fonte

• Ver arquivo Design Patterns\Adaptador\DadoNormal.j
  ava

13
Factory
14
O problema da Pizzaria uma implementação pobre
15
O código fonte

• Ver arquivo
• Design Patterns\Factory\ImplementacaoPobre\Pizza.j
  ava

16
Uma fábrica simples
17
O código fonte

• Ver arquivo
• Design Patterns\Factory\SimpleFactory\Pizza.java

18
O método fábrica
19
O método fábrica

• Define uma interface para criação de um objeto,
  mas deixa as subclasses definirem que classe
  instanciar
• O pattern "Factory Method" permite a uma classe
  delegar a instanciação às subclasses

20
Aplicações

• Uma classe não pode antecipar a classe de objetos
  que deve ser criada
• Uma classe quer que suas subclasses especifiquem
  os objetos que ela cria
• Classes delegam responsabilidades para uma dentre
  várias subclasses auxiliares, e deseja-se
  localizar o conhecimento de qual subclasse
  auxiliar implementa a delegação

21
O método fábrica
22
Conseqüências

• Provê ganchos para as subclasses
• Conecta hierarquias de classes paralelas quando
  há delegação

23
O código fonte

• Ver arquivo
• Design Patterns\Factory\FactoryMethod\Pizza.java

24
Fábrica Abstrata
25
Fábrica Abstrata

• Provê uma interface para a criação de famílias de
  objetos relacionados ou dependentes sem
  especificar suas classes concretas

26
Aplicações

• Um sistema deve ser independente de como seus
  elementos são criados, compostos e representados
• Um sistema deve ser configurado para trabalhar
  com uma única família dentre múltiplas famílias
  de produtos
• Uma família de produtos relacionados é projetada
  para ser usada em conjunto, e há a necessidade de
  reforçar essa restrição
• Se quer criar uma biblioteca de classes de
  produtos, revelando apenas suas interfaces e não
  suas implementações

27
Uma fábrica abstrata
28
Conseqüências

• Isola as classes concretas
• Facilita a troca de famílias de produtos
• Prove consistência entre produtos
• Facilita o suporte a novos tipos de produtos

29
O código fonte

• Ver arquivo
• Design Patterns\Factory\AbstractFactory\Pizza.java

30
Singleton
31
Singleton

• Garante que uma classe tenha apenas uma
  instância, ou um número controlado de instâncias,
  e provê um ponto de acesso global a ela(s).

32
Aplicação

• É usado quando
• deve haver exatamente uma única instância de uma
  classe, e ela deve estar disponível a todos os
  clientes a partir de um ponto de acesso bem
  definido
• quando se deseja que a única instância possa ser
  estendida por herança, e os clientes serem
  capazes de utilizar essa instância estendida sem
  terem de modificar o seu código

33
Estrutura
34
Conseqüências

• Acesso controlado à instância única
• Espaço de nomes reduzido
• Permite refinamento de operações e representação
  via especialização
• Permite um número variável de instâncias
• Maior flexibilidade do que em operações de
  classes

35
O código fonte

• Ver arquivo Design Patterns\Singleton\Pizza.java

36
Strategy
37
Strategy

• O padrão Strategy define uma família de
  algoritmos intercambiáveis e encapsula cada um
  deles fazendo com que eles possam ser
  permutáveis.
• O padrão Strategy permite que os algoritmos
  variem independentemente dos clientes que os
  utilizam

38
Aplicações

• Usado quando muitas classes relacionadas diferem
  apenas em alguns de seus comportamentos
• O padrão Strategy provê uma maneira de configurar
  uma classe com um entre vários comportamentos
  possíveis

39
Estrutura
40
Trocando o comportamento em tempo de execução
41
O código fonte

• Ver arquivos
• Design Patterns\Strategy\ImplementacaoPobre\Teste.
  java
• Design Patterns\Strategy\ImplementacaoMelhor\Teste
  .java
• Design Patterns\Strategy\ComportamentoDinamico\Tes
  te.java

42
Iterator
43
Iterator

• Provê um modo de acessar seqüencialmente
  elementos de um objeto agregado sem expor sua
  representação básica

44
Aplicações

• Serve para acessar o conteúdo de um objeto
  agregado sem expor sua representação interna
• Permite suportar múltiplas varreduras de objetos
  agregados
• Provê uma interface uniforme para varrer
  diferentes estruturas agregadas de forma
  polimórfica

45
Estrutura
46
Conseqüências

• Simplifica a interface do agregado
• Mais de um caminho pode estar pendente em um
  agregado

47
O código fonte

• Ver arquivos
• Design Patterns\Iterator\ImplementacaoPobre\Teste.
  java
• Design Patterns\Iterator\ImplementacaoMelhor\Teste
  .java

48
Composite
49
Composite

• O padrão a ser usado quando você tem coleções de
  objetos com um relacionamento todo-parte e você
  quer ser capaz de tratar estes objetos
  uniformemente
• O padrão Composite fornece uma estrutura para
  armazenar tanto objetos individuais como coleções
  destes objetos
• O padrão Composite permite aos clientes tratar
  objetos individuais e coleções de objetos
  uniformemente

50
Composite
51
Exemplo
52
Composite

• Define uma hierarquia de classes que consiste de
  objetos individuais (Leaf) e objetos compostos
  (Composite).
• Um elemento da árvore é qualquer objeto na
  estrutura do Composite. Elementos podem ser
  objetos individuais ou objetos compostos. Objetos
  compostos, por sua vez, podem ser constituídos de
  objetos individuais e outros objetos compostos, e
  assim por diante.
• Em qualquer ponto do código cliente em que se
  espera um objeto individual, também pode ser
  usado um objeto composto.

53
Composite

• O cliente pode tratar estruturas compostas e
  objetos individuais uniformemente.
• Os clientes normalmente não sabem (e não devem se
  preocupar) se eles estão tratando com um objeto
  individual ou composto.
• Permite a simplificação do código do cliente,
  porque evita escrever funções que tenham que
  testar o tipo das classes que definem a
  composição.

54
Composite

• Torna-se mais fácil adicionar novos tipos de
  componentes basta que eles implementem a
  interface de um elemento da árvore.
• Novas definições das subclasses "Leaf" ou
  "Composite" trabalham automaticamente com as
  estruturas existentes e o código do cliente.
• Os clientes não precisam ser modificados devido a
  criação de novas classes que implementem a
  interface.

55
O código fonte
Ver arquivos Design Patterns\Composite\Simples\Tes
te.java Design Patterns\ Composite\Sofisticada2\T
este.java
56
Facade
57
Facade

• Provê uma interface unificada para um conjunto de
  interfaces em um subsistema.
• Define uma interface de mais alto nível que torna
  mais fácil o uso do subsistema.

58
Aplicações

• Oferecer uma interface simples para um subsistema
  complexo
• Existem muitas dependências entre clientes e as
  classes de implementação de uma abstração.
• A introdução de um "Façade" irá desacoplar o
  subsistema dos clientes dos outros subsistemas,
  promovendo assim, a independência e portabilidade
  desses subsistemas.

59
Aplicações

• Quando se deseja subsistemas em camadas.
• Use um "Façade" para definir um ponto de entrada
  para cada nível do subsistema. Se os subsistemas
  são dependentes, então pode-se simplificar a
  dependência entre eles fazendo com que eles se
  comuniquem uns com os outros unicamente através
  dos seus "Façades".

60
A Biblioteca Uma implementação pobre
61
A Biblioteca Uma implementação pobre
62
A Biblioteca Uma implementação melhor
63
A Biblioteca Uma implementação melhor
64
Conseqüências

• Isola os clientes dos componentes do subsistema,
  reduzindo desse modo o número de objetos com que
  o cliente interage, fazendo com que o subsistema
  seja muito mais fácil de se usar.
• Ajuda a estruturar o sistema em camadas.
• Promove um acoplamento fraco entre o subsistema e
  seus clientes.
• Geralmente os componentes de um subsistema são
  fortemente acoplados. Um baixo acoplamento entre
  subsistemas permite que se varie os componentes
  de um subsistema sem afetar seus clientes.

65
O Código Fonte
Ver arquivos Design Patterns\Facade\ImplementacaoP
obre\Usuario.java Design Patterns\
Facade\ImplementacaoMelhor\Usuario.java
66
Observer
67
Observer

• O padrão Observer define uma relação um para
  muitos entre objetos
• O objeto Observado atualiza os Observadores
  utilizando uma interface comum.
• O objeto Observado e os Observadores são
  fracamente acoplados na medida em que o objeto
  Observado não conhece os Observadores e nada sabe
  sobre eles a não ser que eles implementam a
  interface Observador.

68
Observer

• O objeto observado pode enviar o seu estado aos
  observadores (push) ou disponibilizar métodos de
  acesso para seus dados (pull). Pull é geralmente
  considerado mais correto.
• Seu programa não deve confiar em que as
  notificações aos observadores ocorram numa dada
  ordem.
• Java tem várias implementações do padrão
  Observer, incluindo o Observer genérico
  java.util.Observer

69
Um exemplo
70
Uma implementação ruim
Codificando para uma implementação concreta, não
temos como acrescentar novas apresentações sem
modificar o programa
71
Ainda uma implementação ruim Usando um Objeto de
Transferência de Dados
72
As interfaces Observador e Observavel
73
Usando as interfaces Java Observer e Observable
74
Usando as interfaces Java Observer e Observable
com métodos pull