Title: Design Patterns
1Design Patterns
- A adoção dos padrões terá um efeito profundo e
duradouro sobre a forma de escrevermos programas - Ward Cunningham e Ralph Johnson
2Design 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
3Design 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
4Design 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
5Design Patterns
6O Adaptador
7O 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
8O Adaptador
9O Adaptador
10O Adaptador
11O Adaptador
12O código fonte
- Ver arquivo Design Patterns\Adaptador\DadoNormal.j
ava
13Factory
14O problema da Pizzaria uma implementação pobre
15O código fonte
- Ver arquivo
- Design Patterns\Factory\ImplementacaoPobre\Pizza.j
ava
16Uma fábrica simples
17O código fonte
- Ver arquivo
- Design Patterns\Factory\SimpleFactory\Pizza.java
18O método fábrica
19O 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
20Aplicaçõ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
21O método fábrica
22Conseqüências
- Provê ganchos para as subclasses
- Conecta hierarquias de classes paralelas quando
há delegação
23O código fonte
- Ver arquivo
- Design Patterns\Factory\FactoryMethod\Pizza.java
24Fábrica Abstrata
25Fábrica Abstrata
- Provê uma interface para a criação de famílias de
objetos relacionados ou dependentes sem
especificar suas classes concretas
26Aplicaçõ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
27Uma fábrica abstrata
28Conseqüê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
29O código fonte
- Ver arquivo
- Design Patterns\Factory\AbstractFactory\Pizza.java
30Singleton
31Singleton
- 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).
32Aplicaçã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
33Estrutura
34Conseqüê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
35O código fonte
- Ver arquivo Design Patterns\Singleton\Pizza.java
36Strategy
37Strategy
- 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
38Aplicaçõ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
39Estrutura
40Trocando o comportamento em tempo de execução
41O código fonte
- Ver arquivos
- Design Patterns\Strategy\ImplementacaoPobre\Teste.
java - Design Patterns\Strategy\ImplementacaoMelhor\Teste
.java - Design Patterns\Strategy\ComportamentoDinamico\Tes
te.java
42Iterator
43Iterator
- Provê um modo de acessar seqüencialmente
elementos de um objeto agregado sem expor sua
representação básica
44Aplicaçõ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
45Estrutura
46Conseqüências
- Simplifica a interface do agregado
- Mais de um caminho pode estar pendente em um
agregado
47O código fonte
- Ver arquivos
- Design Patterns\Iterator\ImplementacaoPobre\Teste.
java - Design Patterns\Iterator\ImplementacaoMelhor\Teste
.java
48Composite
49Composite
- 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
50Composite
51Exemplo
52Composite
- 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.
53Composite
- 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.
54Composite
- 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.
55O código fonte
Ver arquivos Design Patterns\Composite\Simples\Tes
te.java Design Patterns\ Composite\Sofisticada2\T
este.java
56Facade
57Facade
- 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.
58Aplicaçõ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.
59Aplicaçõ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".
60A Biblioteca Uma implementação pobre
61A Biblioteca Uma implementação pobre
62A Biblioteca Uma implementação melhor
63A Biblioteca Uma implementação melhor
64Conseqüê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.
65O Código Fonte
Ver arquivos Design Patterns\Facade\ImplementacaoP
obre\Usuario.java Design Patterns\
Facade\ImplementacaoMelhor\Usuario.java
66Observer
67Observer
- 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.
68Observer
- 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
69Um exemplo
70Uma implementação ruim
Codificando para uma implementação concreta, não
temos como acrescentar novas apresentações sem
modificar o programa
71Ainda uma implementação ruim Usando um Objeto de
Transferência de Dados
72As interfaces Observador e Observavel
73Usando as interfaces Java Observer e Observable
74Usando as interfaces Java Observer e Observable
com métodos pull