Prof. Alexandre Bernardes

Introdução Conhecimento e as lições aprendidas por outros

desenvolvedores que tiveram o mesmo problema de design e sobreviveram.

Conhecer os padrões de projetos e depois avaliar os locais que possam ser aplicados.

Em vez da reutilização de código, com os padrões você obtém a reutilização de experiência.

2

Exemplo: Um jogo de simulação de lago com patos de

grande sucesso SimUDuck.

O jogo pode mostrar uma grande variedade de espécies de pato nadando e produzindo sons.

3

A partir de técnicas OO padrão, criaram:

Duck

quack() swim() display() //outros métodos parecidos com duck…

RedheadDuck

display() { //parece um cabeça-vermelha}

MallardDuck

display() { //parece um pato bravo }

Mas agora precisamos dos patos para voar

4

Mas agora precisamos dos patos para VOAR:

Duck

quack() swim() display() fly() //outros métodos parecidos com duck…

RedheadDuck

display() { //parece um cabeça-vermelha}

MallardDuck

display() { //parece um pato bravo }

Problema…

Agora patos de borracha também podem voar…. 5

Ao colocar fly() na superclasse, ele deu capacidade de voar a TODOS os patos, incluindo os que não deveriam voar.

Duck

quack() swim() display() fly() //outros métodos parecidos com duck…

RedheadDuck

display() { //parece um cabeça-vermelha}

MallardDuck

display() { //parece um pato bravo }

RubberDuck

quack() { //substituído por Squeak } fly(){ //substituir para fazer nada} display() { //parece um pato de borracha}

Patos de borracha não grasnam, então quack() é substituído por Squeak

(guincho). 6

Desvantagem do uso de herança para produzir o comportamento do pato. 7

Mudanças vão ocorrer constantemente no projeto

Outra solução

O que acharam? 8

Péssima ideia.

Duplicação de código.

Pois terá que fazer alteração no comportamento vôo de todas as 48 subclasses de vôo de Duck.

ALTERAÇÕES.

No desenvolvimento do Software haverá constantemente….

9

Quais motivos podem causar mudanças?

10

O que fazer agora? Princípio de Projeto.

Então, pegue o que pode variar e “encapsule” para que isso não afete o resto de seu código.

Identifique os aspectos de seu aplicativo que variam e separe-os do que permanece igual

11

Separar o que muda do que fica igual

Esse conceito simples forma a base de quase todos os padrões de projetos.

Todos os padrões fornecem uma maneira de deixar que alguma parte de um sistema varie independentemente de todas as outras partes.

12

Separando o que muda do que fica igual

Problemas de alteração estão nos métodos fly() e quack() que variam entre os patos.

Separar esses comportamentos da classe Duck e criar um novo conjunto de classes.

13

Separando o que muda do que fica igual

14

Separando o que muda do que fica igual

Os comportamentos de Duck ficarão em uma classe separada.

Assim, as classes de Duck não vão precisar conhecer nenhum detalhe de implementação para seus comportamentos.

15

Separando o que muda do que fica igual Será criada uma interface para representar cada

comportamento – por exemplo, Flybehavior e QuackBehavior.

E cada implementação de um comportamento irá implementar uma dessas interfaces.

Exemplo:

16

Separando o que muda do que fica igual

Dessa forma, as subclasses Duck irão usar um comportamento representado por uma interface (FlyBehavior e QuackBehavior).

A implementação real do comportamento não fique presa na subclasse Duck.

17

18

Exemplo simples – para melhor entendimento.

19

20

Com este Projeto:

Outros tipos de objetos podem reutilizar nossos comportamentos de voar e grasnar porque esses comportamentos não são mais escondidos.

Pode-se adicionar novos comportamentos sem modificar nenhuma de nossas classes de comportamento existentes ou,

Ou trocar nenhuma classe Duck que utiliza comportamentos de vôo.

Então obtemos o benefício da reutilização sem toda a bagagem que vem com a herança. 21

Perguntas

P: Usando nosso projeto, o que você faria se precisasse adicionar um vôo de foguete ao aplicativo SimUPato?

R: Criaria uma nova classe FlyRocketPowered que implementasse a interface FlyBehavior. 22

Integrando o comportamento de Duck 1º Adicionar duas variáveis de instância à classe Duck chamadas flyBehavior e quackBehavior.

24

Integrando o comportamento de Duck 2º Implementar o método performQuack():

Nessa parte do código, não importa com o tipo do objeto, só deseja-se saber se ele sabe grasnar (quack()).

25

Integrando o comportamento de Duck 3º Especificar comos as variáveis de instância flyBehavior e quackBehavior são definidas:

26

Implementado o MiniDucksSimulator

28

Implementado o MiniDucksSimulator

29

Implementado o MiniDucksSimulator

30

Implementado o MiniDucksSimulator

31

Implementado o MiniDucksSimulator

32

Configurando o comportamento de forma dinâmica 1º Adicionar dois métodos novos à classe:

34

Configurando o comportamento de forma dinâmica 2º Criar um novo tipo Duck (ModelDuck.java).

35

Configurando o comportamento de forma dinâmica 3º Criar um novo tipo FlyBehavior

(FlyRocketPowered.java)

36

Configurando o comportamento de forma dinâmica 4º Alterar a classe de teste (principal e ativar o ModelDuck para foguete.

public class MiniDuckSimulator{ public static void main(String[] args) { Duck mallard = new MallardDuck(); mallard.performQuack(); mallard.performFly(); Duck model = new ModelDuck(); model.performFly(); model.setFlyBehavior(new FlyRocketPowered()); model.performFly(); } }

37

Visão Geral do Projeto

38

Últimas Observações

Cada pato tem um FlyBehavior e um QuackBehavior aos quais delega as capacidades de voar e de grasnar.

Ao unir as duas classes assim, está usando composição.

Princípio de projeto • Dar prioridade à composição

39

Princípio de Projeto

Usar composição dá muito mais flexibilidade.

Encapsula uma família de algoritmos em seu próprio conjunto de classes.

Além disso, permite alterar o comportamento no tempo de execução desde que o objeto com o qual você estiver compondo implemente a interface de comportamento.

40

Este foi o primeiro padrão de Projeto

Padrão STRATEGY.

• Define uma família de Algoritmos, encapsula cada um dele e os torna intercambiáveis.

• A estratégia deixa o algoritmo variar independentemente dos clientes que o utilizam.

41

Qual a diferença dos dois pedidos?

Vocabulário Compartilhado! 42

O poder de um vocabulário de padrão compartilhado.

Os vocabulários de padrão compartilhado são EFICAZES.

Os padrões permitem dizer mais com menos.

Falar com padrões permite que você permaneça “no projeto” por mais tempo.

Vocabulários compartilhados podem turbinar sua equipe de desenvolvimento.

43

Exercício

45

46

Exemplo: Estação Meteorológica baseada na Internet de próxima geração. A estação meteorológica será baseada em nosso objeto

WeatherData, que monitora condições atuais do tempo (temperatura, umidade e pressão barométrica).

Deseja-se criar um aplicativo que fornecesse inicialmente três elementos de exibição: Condições atuais, estatísticas meteorológicas e uma simples previsão, todos atualizados em tempo real à medida que o objeto WeatherData adquirir as medições mais recentes.

Criar uma API para que outros desenvolvedores possam escrever seus próprios visores meteorológicos e os conectem.

48

Visão geral do aplicativo Weather Monitoring

49

Desempacotando a classe Weather Data

50

Tarefa a ser realizada

51

Tarefa a ser realizada

52

Primeira implementação – Será que é bom?

53

Com base em nossa primeira implementação, quais das seguintes opções se aplicam?

54

55

Define a dependência um-para-muitos entre objetos para que quando um objeto mude de estado todos os seus dependentes sejam avisados e atualizados automaticamente.

Padrão Observer Possui:

Subject (Sujeitos)

Observers (Observadores)

O sujeito e os observadores definem a relação um-para-muitos.

Os observadores dependem do sujeito de modo que quando o estado sujeito for alterado os observadores são avisados.

Dependendo do estilo de notificação, o observador também pode ser atualizado com novos valores.

57

58

Conhecendo o Padrão Observer

59

Conhecendo o Padrão Observer

60

Conhecendo o Padrão Observer

61

Conhecendo o Padrão Observer

62

Conhecendo o Padrão Observer

63

Conhecendo o Padrão Observer

64

Conhecendo o Padrão Observer

65

67

68

70

71

72

73

74

75

Bibliografia SIERRA, K. et al. Use a Cabeça! Padrões de Projetos. 2

ed. Alta Books: Rio de Janeiro, 2009.

76