Padrões de Projeto Aula 5 – Padrão Decorator 1. QuickReview: Observer Definição: Quando usar? Tipo de padrão? Como? 2.

Apresentação em tema: "Padrões de Projeto Aula 5 – Padrão Decorator 1. QuickReview: Observer Definição: Quando usar? Tipo de padrão? Como? 2."— Transcrição da apresentação:

1 Padrões de Projeto Aula 5 – Padrão Decorator 1

2 QuickReview: Observer Definição: Quando usar? Tipo de padrão? Como? 2

3 PADRÃO DECORATOR Anexa responsabilidades adicionais a um objeto de maneira dinâmica. 3

4 Starbuzz Coffee Cenário – Starbuzz Coffee ficou conhecido como o café com o crescimento mais rápido da região. Se você já viu um na sua esquina, olhe para o outro lado da rua: você verá outro. – Como eles cresceram muito rápido, estão tendo dificuldades em atualizar seus sistemas de pedidos para corresponder a suas ofertas de bebidas. 4

5 Quando eles entraram no negócio, projetaram suas classes assim: calcularPreco() é abstrato, para que as subclasses defi- nam sua implementação. 5

6 Além do seu café, você pode pedir vários adicionais. Dê uma olhadinha no cardápio. Os adicionais são o atrativo desse lugar! Cada adicional tem um preço, e portanto devemos incluí-los no sistema. 6

7 Temos o café e os adicionais... Como o café deve ser montado dinamicamente? Como esse preço deve ser calculado dinamicamente? 7

8 Solução I: uma classe para cada combinação Tradicional + Leite; Tradicional + Espuma; Tradicional + Leite + Espuma,... Cada classe calcula o preço do café com o seu adicional. Isso nos daria uma combinação de quantas classes? E quando o leite aumentar? E quando um novo adicional entrar? CANCELADA! 8

9 Solução II: variáveis para representar os adicionais Leite, espuma, creme, chocolate Calcula o custo total dos adicionais. Retorna o preço de cada bebida + adicionais. Baixíssima coesão! E se o preço dos adicionais mudarem? E se surgirem novos condimentos? E se chá gelado entrar no cardápio? E se um cliente quiser 2x creme? 9

10 10

11 O princípio Aberto-Fechado Herança nem sempre leva a designs flexíveis e fáceis de manter. – Um meio mais interessante de “herdar” comportamento é via composição. (Um dos princípios é: prefira composição à herança) Compondo objetos de formas dinâmicas é possível adicionar novas funcionalidades através da criação de um código novo, ao invés de alterar o já existente. As classes devem estar abertas para extensão mas fechadas para modificação. 11

12 Ok... Então, qual é a melhor solução para StarBuzz? 12

13 Solução 3 (a melhor entre elas): PADRÃO DECORATOR! Considera os princípio de herança/composição e aberto/fechado. 13

14 Solução III: padrão Decorator O cliente primeiro escolhe o tipo de bebida, e depois escolhe os adicionais em tempo de execução (real life). Senhor, pode me falar o seu pedido... Desejo um café tradicional... Com quais adicionais, senhor? Com chocolate... Mais algum adicional, senhor? E com leite! Ok, senhor! Só um minutinho, já digo quanto custa. ;-) 14

15 Solução III: padrão Decorator Vamos lá: 1.Café tradicional: R$1.50 2.Adicional de chocolate: R$1.00 3.Adicional de leite: R$0.50 Custa 3 reais, senhor! 15

16 Em termos de implementação, como é possível decorar os objetos? 1.Começamos com o objeto Cafe- Tradicional. 2.Criamos um objeto Chocolate e englobamos CafeTradicional nele. 3.Criamos um decorador Leite e colocamos Chocolate dentro. calcularPreco() Leite calcularPreco() CafeTradicional calcularPreco() Chocolate calcularPreco() CafeTradicional calcularPreco() CafeTradicional calcularPreco() Chocolate 16

17 E como é calculado o preço desse café e seus adicionais? calcularPreco() Leite calcularPreco() CafeTradicional calcularPreco() Chocolate 1. Chamamos calcularPreco() do decorador externo, Leite. 2. Leite chama calcularPreco() de Chocolate. 3. Chocolate chama calcular- Preco() de CafeTradicional. 4. CafeTradicional re- torna seu valor. 5. Chocolate retorna seu valor + CafeTradicional 6. Leite retorna seu valor + Chocolate, que é o valor total. 17

18 Terminologia e estrutura 18

19 19 Componentes aos quais adicionamos dinamicamente um novo comportamento. Os decoradores precisam ser da mesma interface dos componentes porque serão englobados do mesmo modo que a interface é. Bebida bebida = new CafeTradicional(); bebida = new ChocolateDecorator(bebida); Os decoradores englobam um componente.

20 Bebida, a nossa interface. 20 Onde calculamos o preço de um CafeTradicional.

21 21 Onde calculamos o preço do Chocolate + CafeTradicional. Bebida que estamos englobando. Os decoradores precisam ser do mesmo tipo que as bebidas.

22 22 Pedido: Um café tradicional, com chocolate, com leite. Resultado...

23 Categoria: padrão do tipo estrutural – O padrão funciona como um wrapper para classes existentes – Este padrão cria uma classe decoradora que empacota a classe original para prover novas funcionalidades. Tudo isto é feito sem que haja alteração na estrutura da classe. – Ao contrário da herança, que aplica funcionalidade a todos os objetos dela, ele permite adicionar funcionalidades a um objeto específico sem alterar a estrutura da classe. (composição) 23

24 Os decoradores têm o mesmo supertipo que os objetos que eles decoram; É permitido usar 1/+ decoradores para englobar um objeto; Os objetos podem ser decorados dinamicamente em tempo de execução. 24

25 Exercício Implementem a solução para o StarBuzz seguindo a UML abaixo. Para testar seu programa, crie as seguintes bebidas: – Café tradicional + leite + chocolate – Café Blend + leite + leite + espuma – Café descafeinado + leite + chocolate + creme + espuma 25

26 Tarefa de Casa Ler capítulos 1, 2 e 3 do livro Use a Cabeça – Padrões de Projeto – Faça os exercícios proposto pelo livro – Faça um resumos dos princípios de projeto. Entenda e saiba explicar cada um deles. – Reimplemente os exercícios da aula: Strategy: Mortal Kombat Observer: Editora de Revista + Assinantes Decorator: Starbuzz Coffee 26

27 Referências – O caso Starbuzz é abordado no capítulo 3 do livro “Padrões de Projeto – Use a Cabeça!” 27