QuickReview: Observer Definição:

Slides:



Advertisements
Apresentações semelhantes
Aula 5 – Padrão Decorator
Advertisements

Padrões de Projeto Aula 5 – Padrão Decorator 1. QuickReview: Observer Definição: Quando usar? Tipo de padrão? Como? 2.
EA976 – Engenharia de Software AULA 9 De Módulos a Objetos.
Tecnologias para Internet Thyago Maia Tavares de Farias Aula 19.
Linguagem de Programação – Aula 03 Prof. Me. Ronnison Reges Vidal.
Nome Autor 1 Nome Autor 2 Nome Autor 3 Nome da Minha Instituição de Ensino Título do Meu Trabalho Apresentado na Escola Regional de Redes (ERRC 2016) Logotipo.
Diagrama de Use Cases. Objetivo  O Diagrama de Use Cases tem o objetivo de auxiliar a comunicação entre os analistas e o cliente.
Strategy Definição: Quando usar? Tipo de padrão? Como?
Tutorial Endosso Rápido
UML – Diagramas de componentes
Diagrama de Use Cases.
Singleton Definição: Quando usar? Tipo de padrão? Como? estrutural.
Inovação de Valor É preciso ir além da demanda existente!
Aula 7 – Padrão Abstract Factory
Sistemas Prof. Luis S. B. Marques MINISTÉRIO DA EDUCAÇÃO
Corpos Rígidos: Sistemas Equivalentes de Forças
IP – Condicionais e controle de fluxo
Sistemas de Controle III N8SC3
Aula 9 – Padrão Decorator
Conflitos interpessoais e a dinâmica da negociação
PLANEJAMENTO E ESTRATÉGIA
Aula 14 – Padrão Abstract Factory
UML – Diagramas de Componentes e Modelação da Arquitectura Física
Algoritmos e Fluxogramas
Aula 11 – Padrão Singleton
PIT – PROGRAMA INTERNO DE TREINAMENTO 2015
Engenharia de Software II
LIMITE DE UMA FUNÇÃO Aula 01 – Matemática I – Engenharia de Aquicultura Prof. Danilene Donin Berticelli.
IP – Repetições Prof. Eduardo Falcão.
Parte III – Planejando o Projeto
Introdução à Programação
Programação Orientada a Objetos
Programação Orientada a Objetos
Diagramas de Sequência
Método Simplex Montar um dicionário inicial
Engenharia de Software Analise de Riscos
Programação.
ESTATÍSTICA AULA 04 ANÁLISE EXPLORATÓRIA DE DADOS I – Unidade 3
Aula 8 – Padrão Singleton
Termodinâmica e Estrutura da Matéria Entropia
Leia tudo a respeito Microsoft Notícias do SharePoint
MICROECONOMIA Aula 6 – Análise da Teoria da Produção.
Pacotes Servem para organizar o código, por exemplo, agrupar classes correlatas. Vamos supor uma classe Ponto2D pertencente ao pacote formas. A classe.
Aula 3.2.
Conflitos interpessoais e a dinâmica da negociação
Planejamento Estratégico para Exportação
Rosemary Silveira Filgueiras Melo
Laboratório I Mateus Raeder.
Termodinâmica e Estrutura da Matéria Entropia
Estruturas de Dados aula 3
Laboratório I Mateus Raeder.
Como Investigar um Acidente de Trabalho
Classes de palavras: CONECTIVOS.
Dinâmica de Sistemas Uma visão geral.
Variância e Desvio padrão
Nome do Produto.
Princípios de Telecomunicações
Modelo de Análise.
Introdução à Economia Pedro Telhado Pereira.
Prof. Rafael Mesquita Listas Encadeadas Prof. Rafael Mesquita
PERSONIFICANDO A MINHA IDENTIDADE.
Modelagem de Sistemas
N Q E modelo VIAGENS S Como projetar uma localização com base em uma viagem de campo visualizada por outros estudantes. Um modelo para alunos criarem.
Prof. Ricardo Luís Lachi
S.O.L.I.D.
Prof. Elisson de Andrade
Análise ESTÁTICA COMPARATIVA
Prof. Elisson de Andrade
Arquitetura e padrões de software
Prof. Elisson de Andrade
Transcrição da apresentação:

QuickReview: Observer Definição: Quando usar? Tipo de padrão? Como? Def: padrão usado quando existe uma relação um-para-muitos entre os objetos, de modo que sempre que o objeto principal (subject) for modificado seus objetos dependentes (observers) sejam notificados automaticamente. Quando usar? Quando existir uma relação de dependência um-para-muitos. Tipo de padrão? Comportamental (padrões comportamentais são basicamente padrões de comunicações entre os objetos) Como? Interfaces Subject e Observer Lembrar de programar para superclasses! Assim podemos ter uma maior gama de observadores. ;-)

"Não, a pintura não é feita para decorar os apartamentos "Não, a pintura não é feita para decorar os apartamentos. É um instrumento de guerra ofensiva e defensiva contra o inimigo. “ - Pablo Picasso POO Decorator Prof. Eduardo Falcão

Padrão decorator Anexa responsabilidades adicionais a um objeto de maneira dinâmica.

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.

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

Os adicionais são o atrativo desse lugar! 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.

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

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

Solução II: variáveis para representar os adicionais Leite, espuma, creme, chocolate 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? Calcula o custo total dos adicionais. E se o preço dos adicionais mudarem? Será preciso alterar o código existente. E se surgirem novos condimentos? Será preciso adicionar novos métodos. E se chá gelado entrar no cardápio? Ele vai herdar métodos que tira a semântica e coesão do sistema. Faz sentido tomar chá gelado com creme? E se um cliente quiser um moca (chocolate) duplo? O nosso sistema simplesmente não suporta. Retorna o preço de cada bebida + adicionais.

Pág 62 do livro use a cabeça ou 81 do PDF use a cabeça.

O princípio Aberto-Fechado As classes devem estar abertas para extensão mas fechadas para modificação. 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. Quais são os demais princípios? Se não lembra, estude!

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

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

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). Ok, senhor! Só um minutinho, já digo quanto custa. ;-) Mais algum adicional, senhor? Com quais adicionais, senhor? Senhor, pode me falar o seu pedido... E com leite! Desejo um café tradicional... Com chocolate...

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

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

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

Terminologia e estrutura

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 é. Componentes aos quais adicionamos dinamicamente um novo comportamento. Bebida bebida = new CafeTradicional(); bebida = new ChocolateDecorator(bebida); Os decoradores englobam um componente.

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

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

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

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)

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.

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

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

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