Design Patterns - GoF

74
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

Transcript of Design Patterns - GoF

Page 1: Design Patterns - GoF

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

Page 2: Design Patterns - GoF

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

Page 3: Design Patterns - GoF

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

Page 4: Design Patterns - GoF

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

Page 5: Design Patterns - GoF

Design Patterns

Page 6: Design Patterns - GoF

O Adaptador

Page 7: Design Patterns - GoF

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

Page 8: Design Patterns - GoF

O Adaptador

Page 9: Design Patterns - GoF

O Adaptador

Page 10: Design Patterns - GoF

O Adaptador

Page 11: Design Patterns - GoF

O Adaptador

Page 12: Design Patterns - GoF

O código fonte

Ver arquivo Design Patterns\Adaptador\DadoNormal.java

Page 13: Design Patterns - GoF

Factory

Page 14: Design Patterns - GoF

O problema da Pizzaria: uma implementação pobre

Page 15: Design Patterns - GoF

O código fonte

Ver arquivo

Design Patterns\Factory\ImplementacaoPobre\Pizza.java

Page 16: Design Patterns - GoF

Uma fábrica simples

Page 17: Design Patterns - GoF

O código fonte

Ver arquivo

Design Patterns\Factory\SimpleFactory\Pizza.java

Page 18: Design Patterns - GoF

O método fábrica

Page 19: Design Patterns - GoF

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

Page 20: Design Patterns - GoF

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

Page 21: Design Patterns - GoF

O método fábrica

Page 22: Design Patterns - GoF

Conseqüências

• Provê ganchos para as subclasses

• Conecta hierarquias de classes paralelas quando há delegação

Page 23: Design Patterns - GoF

O código fonte

Ver arquivo

Design Patterns\Factory\FactoryMethod\Pizza.java

Page 24: Design Patterns - GoF

Fábrica Abstrata

Page 25: Design Patterns - GoF

Fábrica Abstrata

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

Page 26: Design Patterns - GoF

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

Page 27: Design Patterns - GoF

Uma fábrica abstrata

Page 28: Design Patterns - GoF

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

Page 29: Design Patterns - GoF

O código fonte

Ver arquivo

Design Patterns\Factory\AbstractFactory\Pizza.java

Page 30: Design Patterns - GoF

Singleton

Page 31: Design Patterns - GoF

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).

Page 32: Design Patterns - GoF

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

Page 33: Design Patterns - GoF

Estrutura

Page 34: Design Patterns - GoF

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

Page 35: Design Patterns - GoF

O código fonte

Ver arquivo Design Patterns\Singleton\Pizza.java

Page 36: Design Patterns - GoF

Strategy

Page 37: Design Patterns - GoF

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

Page 38: Design Patterns - GoF

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

Page 39: Design Patterns - GoF

Estrutura

Page 40: Design Patterns - GoF

Trocando o comportamento em tempo de execução

Page 41: Design Patterns - GoF

O código fonte

Ver arquivos

Design Patterns\Strategy\ImplementacaoPobre\Teste.java

Design Patterns\Strategy\ImplementacaoMelhor\Teste.java

Design Patterns\Strategy\ComportamentoDinamico\Teste.java

Page 42: Design Patterns - GoF

Iterator

Page 43: Design Patterns - GoF

Iterator

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

Page 44: Design Patterns - GoF

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

Page 45: Design Patterns - GoF

Estrutura

Page 46: Design Patterns - GoF

Conseqüências

• Simplifica a interface do agregado

• Mais de um caminho pode estar pendente em um agregado

Page 47: Design Patterns - GoF

O código fonte

Ver arquivos

Design Patterns\Iterator\ImplementacaoPobre\Teste.java

Design Patterns\Iterator\ImplementacaoMelhor\Teste.java

Page 48: Design Patterns - GoF

Composite

Page 49: Design Patterns - GoF

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

Page 50: Design Patterns - GoF

Composite

Page 51: Design Patterns - GoF

Exemplo

Alberto Antonio

dptoA dptoB

Brito Batista dptoB1

Bento Bezerra

dptoC

Carlos Cardoso

empresa

Page 52: Design Patterns - GoF

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.

Page 53: Design Patterns - GoF

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.

Page 54: Design Patterns - GoF

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.

Page 55: Design Patterns - GoF

O código fonte

Ver arquivos

Design Patterns\Composite\Simples\Teste.java

Design Patterns\ Composite\Sofisticada2\Teste.java

Page 56: Design Patterns - GoF

Facade

Page 57: Design Patterns - GoF

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.

Page 58: Design Patterns - GoF

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.

Page 59: Design Patterns - GoF

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".

Page 60: Design Patterns - GoF

A Biblioteca: Uma implementação pobre

Page 61: Design Patterns - GoF

A Biblioteca: Uma implementação pobre

Page 62: Design Patterns - GoF

A Biblioteca: Uma implementação melhor

Page 63: Design Patterns - GoF

A Biblioteca: Uma implementação melhor

Page 64: Design Patterns - GoF

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.

Page 65: Design Patterns - GoF

O Código Fonte

Ver arquivos

Design Patterns\Facade\ImplementacaoPobre\Usuario.java

Design Patterns\ Facade\ImplementacaoMelhor\Usuario.java

Page 66: Design Patterns - GoF

Observer

Page 67: Design Patterns - GoF

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.

Page 68: Design Patterns - GoF

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

Page 69: Design Patterns - GoF

Um exemplo

Page 70: Design Patterns - GoF

Uma implementação ruim

Codificando para uma implementação concreta, não temos como acrescentar novas apresentações sem modificar o programa

Page 71: Design Patterns - GoF

Ainda uma implementação ruim: Usando um Objeto de Transferência de Dados

Page 72: Design Patterns - GoF

As interfaces Observador e Observavel

Page 73: Design Patterns - GoF

Usando as interfaces Java Observer e Observable

Page 74: Design Patterns - GoF

Usando as interfaces Java Observer e Observable com métodos pull