Design Patterns - PowerPoint PPT Presentation

1 / 74
About This Presentation
Title:

Design Patterns

Description:

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 – PowerPoint PPT presentation

Number of Views:267
Avg rating:3.0/5.0
Slides: 75
Provided by: Jonas152
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com