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.

Apresentação em tema: "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."— Transcrição da apresentação:

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

10

11

12 O código fonte Ver arquivo Design Patterns\Adaptador\DadoNormal.java

13 Factory

14 O problema da Pizzaria: uma implementação pobre

15 O código fonte Ver arquivo Design Patterns\Factory\ImplementacaoPobre\Pizza.java

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 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 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 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 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\Teste.java

42 Iterator

43 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 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\Teste.java Design Patterns\ Composite\Sofisticada2\Teste.java

56 Facade

57 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

62 A Biblioteca: Uma implementação melhor

63

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\ImplementacaoPobre\Usuario.java Design Patterns\ Facade\ImplementacaoMelhor\Usuario.java

66 Observer

67 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