Upload
talita-pagani
View
607
Download
51
Embed Size (px)
DESCRIPTION
Aula 2 de Design Patterns da Pós-graduação em Engenharia de Software.
Citation preview
Prof.ª Esp. Talita Pagani [email protected] | @talitapagani
Especialização em Engenharia de Software
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 1
1. Definição de Design Patterns
2. Design Patterns para softwares orientados a objetos
a. Padrões de criação;
b. Padrões estruturais;
c. Padrões comportamentais;
3. Estudo de caso de Design Patterns;
4. Modelagem de software com auxílio de Design Patterns
5. Design Patterns para interfaces gráficas;
6. Design Patterns para mobile.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 2
Informações gerais
• Cria uma instância de várias famílias de classes.
• Quando e onde usar: – Para criar famílias de objetos
relacionados ou dependentes;
– Quando é necessário isolar classes concretas de suas superclasses;
– Quando um sistema precisa de independência de como seus produtos são criados, compostos e representados.
Padrões de criação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 3
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Separa a construção de um objeto complexo de sua representação.
• Quando e onde usar: – Quando for necessário criar um
objeto complexo, especificando apenas seu tipo e conteúdo. O objeto construído está protegido dos detalhes de sua construção;
– Quando se deseja dissociar o processo de construção de um objeto complexo a partir das partes que compõem o objeto;
– Quando é necessário isolar o código para a construção e representação.
Padrões de criação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 4
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Cria uma instância de várias classes derivadas.
• Quando e onde usar: – Quando uma classe quer que
suas subclasses especifiquem o objeto;
– Quando uma classe não pode antecipar suas subclasses;
– Quando uma família de objetos precisa ser separada utilizando uma interface comum;
– Para esconder classes concretas;
– Para parametrização na criação de objetos.
Padrões de criação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 5
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Uma instância completa a ser copiada ou clonada.
• Quando e onde usar: – Quando há muitas subclasses que
diferem apenas no tipo de objetos;
– Quando um sistema precisa de independência de como seus produtos são criados, compostos e representados;
– Quando é necessário adicionar ou remover objetos em tempo de execução;
– Quando é necessário especificar novos objetos, alterando a estrutura, ou configurando uma aplicação com classes dinâmicas.
Padrões de criação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 6
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela.
• Quando e onde usar: – Quando é necessário criar
uma instância única, definindo uma classe final;
– Ao desejar controlar a instanciação de uma classe com um valor compartilhado por todas as instâncias.
Padrões de criação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 7
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Casa interfaces de diferentes classes.
• Quando e onde usar: – Ao necessitar de
delegação de objetos;
– Quando é necessário fazer com que classes não relacionadas trabalhem juntas.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 8
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Separa a interface de um objeto de sua implementação.
• Quando e onde usar: – Quando se quer separar a
abstração da implementação de forma permanente;
– Quando se quer melhorar a extensibilidade;
– Quando se deseja ocultar detalhes de implementação.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 9
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Uma estrutura em árvore de objetos simples e consistentes.
• Quando e onde usar: – Quando se deseja agrupar
componentes para formar componentes maiores que, por sua vez, podem ser agrupados para formar componentes ainda maiores.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 10
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Adiciona responsabilidades a um objeto dinamicamente.
• Quando e onde usar: – Quando é necessário
adicionar uma nova função para um objeto sem afetar outros objetos.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 11
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Uma classe que representa todo um subsistema.
• Quando e onde usar: – Em sistemas complexos,
quando se deseja reduzir a complexidade;
– Quando é necessário minimizar a comunicação e a dependência entre subsistemas.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 12
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Uma instância granularizada usada para compartilhamento eficiente.
• Quando e onde usar: – Quando é preciso instanciar
uma grande quantidade de classes pequenas e granuladas;
– Quando é necessário ícones para representar objetos;
– Para ter um estado de objeto extrínseco, que pode ser compartilhado entre classes.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 13
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Um objeto que representa outro objeto.
• Quando e onde usar: – Se a criação do objeto é muito
custosa em tempo e memória;
– Se é necessário adiar a criação do objeto até que você precise do mesmo;
– Quando é necessário realizar operações que consomem tempo, como carregar uma imagem grande;
– Quando é necessário permissões de acesso para um sistema complexo.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 14
Padrões estruturais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Uma forma de passar uma requisição entre uma cadeia de objetos.
• Quando e onde usar: – Quando uma requisição
deve ser tratada por mais de um objeto;
– Quando não é possível saber qual objeto deve lidar com a requisição.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 15
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Encapsula a requisição de um comando como um objeto.
• Quando e onde usar: – Quando uma ação pode ser
representada de várias formas;
– Quando há necessidade de desfazer uma ação, armazenando seus estados para mais tarde recuperá-los.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 16
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Inclui elementos de linguagem em um programa.
• Quando e onde usar: – Quando é necessário o
seu próprio gerador de interpretador;
– Para traduzir uma expressão específica;
– Ao tratar uma informação em árvore.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 17
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Acessa sequencialmente os elementos de uma coleção.
• Quando e onde usar: – Quando é necessário
distinguir variações transversais de um aggregate;
– Quando é necessário filtrar alguma informação de uma coleção de agregação.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 18
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Define uma comunicação simplificada entre classes.
• Quando e onde usar: – Quando é necessário
particionar um sistema em pequenos objetos;
– Quando é necessário limitar subclasses;
– Quando a relação entre a classe de controle e outras classes participantes é multidirecional.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 19
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Captura e restaura o estado interno de um objeto.
• Quando e onde usar: – Quando é necessário
funções de desfazer e refazer;
– Use para gerenciar transações de banco de dados.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 20
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Notifica uma alteração a um determinado número de classes.
• Quando e onde usar: – Quando uma mudança afeta
um ou mais objetos;
– Quando o comportamento de muitos objetos depende de um ou mais estados;
– Quando é necessário comunicação em broadcast.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 21
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Altera o comportamento de um objeto quando seu estado é alterado.
• Quando e onde usar: – Quando é necessário
controlar muitos estados sem o uso de declarações if-else ou switch;
– Quando cada estado deve agir de forma semelhante e deve ser uma subclasse de uma mesma superclass.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 22
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Encapsula um algoritmo dentro de uma classe.
• Quando e onde usar: – Quando é preciso
encapsular vários algoritmos para desempenhar funções semelhantes, mas estes algoritmos são permutáveis e variam de forma independente;
– Use para reduzir instruções condicionais.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 23
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Define as etapas exatas de um algoritmo a uma subclasse.
• Quando e onde usar: – Para fazer template de
operações similares;
– Quando é necessário passar de muitas operações especializadas para uma operação genérica.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 24
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
• Define uma nova operação a uma classe sem alterá-la.
• Quando e onde usar: – Quando é necessário
adicionar operações a várias classes que possuem interfaces diferentes.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 25
Padrões comportamentais
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP, 2012, DOFACTORY, 2014.
Criacionais • Foco: criação de objetos complexos
• Esconde como objetos complexos são criados
Estruturais
• Foco: compor objetos para formar estruturas robustas
• Cria novas funcionalidades a partir de funcionalidades
antigas
• Provê flexibilidade e extensibilidade
Comportamentais
• Foco: algoritmos e atribuição de responsabilidades a
objetos
• Evita acoplamento forte a uma solução em particular
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 26
Design Patterns para softwares orientados a objetos
• Proxy: pode ser de 3 tipos
– Remote proxy
• Cache de informação
– Virtual Proxy
• Para objetos que consomem tempo e tamanho
– Protection Proxy
• Controle de acesso
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 27
Design Patterns para softwares orientados a objetos
• Abstract Factory para um jogo
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 28
Design Patterns para softwares orientados a objetos
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 29
Game
Match
TTTMatch ChessMatch
Chess TicTacToe
createMatch() createStats()
Statistics
TTTStats ChessStats
Tournament
createMatch() createStatistics()
createMatch() createStats()
Se no documento de requisitos constar... Significa...
“independente de dispositivo”
“deve suportar uma família de produtos”
Abstract Factory
“deve se comunicar com objetos
existentes”
Adapter
“deve se comunicar com diversos
sistemas, sendo que alguns serão
desenvolvidos futuramente”
“um protótipo inicial deve ser
demonstrado”
Bridge
“deve se comunicar com um conjunto
existente de objetos”
Façade
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 30
Design Patterns para softwares orientados a objetos
Se no documento de requisitos constar... Significa...
“estrutura complexa”
“deve variar em profundidade e largura”
Composite
“deve ser transparente quanto à
localização do acesso”
Proxy
“deve ser extensível e/ou escalável” Observer
“deve prover uma política de
funcionamento independente do
mecanismo”
Strategy
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 31
Design Patterns para softwares orientados a objetos
• Encapsulamento
• Generalista
• Abstração
• Equilíbrio
• Abertura
• Combinatoriedade
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 32
Design Patterns para softwares orientados a objetos
Estudo de caso
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 33
• Sistema de colaboração entre componentes (AMMAR, 2008) – Rastrear os estados
de três componentes colegas e manter os seus estados idênticos.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 34
Estudo de caso
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 35
Estudo de caso
Figura 1 - Diagrama de Classe antes de aplicar o padrão.
Fonte: AMMAR, 2008.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 36
Estudo de caso
Figura 3 - A estruturação das classes utilizando o padrão Mediator.
Fonte: AMMAR, 2008.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 37
Estudo de caso
Figura 4 – Comunicação entre as classes com o Mediator.
Fonte: AMMAR, 2008.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 38
Estudo de caso
Figura 2 - Diagrama de Classe depois de aplicar o Mediator.
Fonte: AMMAR, 2008.
• O padrão Mediator reduz a
dependência entre os componentes
e aumenta a reusabilidade,
extensibilidade e manutenibilidade
da arquitetura do software.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 39
Estudo de caso
Estudo de caso
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 40
• A estrutura ideal de um subsistema consiste
de:
– Uma interface;
– Um conjunto de objetos de domínio do
aplicativo (entidades) para modelar entidades
reais ou sistemas existentes;
– Um ou mais objetos de controle;
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 41
Estudo de caso
• Realização do objeto Interface: Façade
– Provê uma interface de acesso ao subsistema
• Interface ao sistema existente: Adapter ou Bridge
– Provê a interface para os sistemas legados
– Os sistemas existentes não precisam ser necessariamente orientados a objetos
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 42
Estudo de caso
• Façade – Deve ser oferecido por todos os sistemas em um sistema
como um serviço
• Adapter – Deve ser utilizado como uma interface para os componentes
existentes
• Bridge – Deve ser utilizado como uma interface para um conjunto de
objetos, quando o conjunto completo de objetos não é completamente conhecido
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 43
Estudo de caso
• Similaridades – Ambos são utilizados para esconder detalhes de
implementação.
• Diferenças – Adapter: para objetos que geralmente não trabalham
juntos • Herança seguida de delegação
– Bridge: para deixar as abstrações e implementações variarem independentemente • Delegação seguida de herança
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 44
Estudo de caso
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 45
Estudo de caso
Herança
Delegação Delegação
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 46
• Selecionando padrões:
– Considere como padrões de projeto solucionam
problemas de projeto;
– Examine as seções de Intenção;
– Estude como os padrões se interrelacionam;
– Estude padrões de finalidades semelhantes;
– Examine uma causa de reformulação de projeto ou
considere o que deveria ser variável no seu projeto.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 47
Laboratório 1
• Imagine uma situação onde você precisa implementar um balanceador de carga para gerenciar conexão com servidores.
• Apenas uma única instância da classe pode ser criada, pois os servidores podem ficar online e offline dinamicamente e cada requisição deve passar por um objeto que tenha conhecimento da web farm.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 48
Laboratório 1
• Solução: Singleton
– Uma única operação de instanciação;
– Criar e dar manutenção a esta única instância.
• Exemplo de código: p. 21 da apostila
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 49
Laboratório 1
• Você está desenvolvendo um plugin de comentários para páginas de um sistema gerenciador de conteúdo (CMS).
• Este plugin deve enviar um e-mail quando um comentário é adicionado, sendo que o mailer é uma função intrínseca do CMS.
• Dessa forma, ao adicionar um comentário, o Mailer deve estar ciente de que deve enviar um e-mail para o autor da página.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 50
Laboratório 1
• Solução: Observer
– Comportamento em que a alteração do estado
de um objeto afeta outro;
– Modificar o Mailer para que ele seja uma classe
observadora.
• Exemplo de código: p. 24 da apostila
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 51
Laboratório 1
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 52
Laboratório 1
• Formar grupos de 4 a 5 pessoas
• Duas situações para identificar os padrões
• Esboçar um diagrama no Astah Community
• 45min para cada situação apresentada
• Para cada situação, definir: Qual o pattern que poderia ser utilizado?
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 53
Laboratório 1
• Você está desenvolvendo uma aplicação para agilizar a
criação de documentos usando modelos pré-definidos, que
atualmente suporta dois tipos: Relatórios e Currículos.
• A ferramenta precisa ser flexível para a criação destes
documentos. Embora eles tenham propriedades em comum
(ambos têm páginas), um Relatório deve conter tipos de
páginas para introdução, resultados, conclusão, sumário e
bibliografia, enquanto que um currículo possui páginas de
habilidades, formação e experiência profissional.
• Ao criar um Relatório ou um Currículo, ele já deve produzir
(retornar) estas páginas padrões.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 54
Laboratório 1
• Em um dado sistema de e-commerce, os produtos
podem ser classificados em categorias pré-
determinadas, que compõem o menu de
navegação do site, e em tags, que são
classificações atribuídas pelos consumidores.
• Ambas conectam com o mesmo banco de dados e
precisam ser retornadas da mesma forma, sendo
selecionadas do banco de dados e listadas na tela.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 55
Laboratório 1
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 56
• Nesta atividade, você deverá selecionar uma
situação vivenciada no seu cotidiano de
trabalho onde você já implementou ou poderia
implementar ao menos um design pattern.
Descreva qual o problema resolvido (ou que
poderia ser resolvido) e porque aquele(s)
pattern(s) foi(foram) escolhidos (ou poderiam
ser escolhidos) para resolver esta situação.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 57
Tarefas
• Cada grupo, de 4 a 5 pessoas, deverá montar um conjunto de, no mínimo, 5 patterns identificados através de situações vivenciadas no cotidiano de trabalho. Os patterns identificados podem ser diversos: algoritmos, soluções de interface ou processos.
• O importante é que eles sejam válidos como uma solução de sucesso utilizada para resolver um problema recorrente.
22/02/2014 Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani 58
Tarefas
• ALEXANDER, C., et al. A Pattern Language. Oxford University Press, 1977.
• AMMAR, H. H. 2008. Case Studies on Design Patterns. Disponível em: http://www.csee.wvu.edu/~ammar/rts/adv rts/design patterns
case studies/before and after CaseStudies.ppt
• BRUEGGE, B.; DUTOIT, A. H. 2014. Object-Oriented Software Engineering. Disponível em:
http://www.cs.bilkent.edu.tr/~ugur/teaching/cs319/
• DOFACTORY. 2014. .NET Design Patterns. Disponível em: http://www.dofactory.com/Patterns/Patterns.aspx
• GAMMA, E., et al. Padrões de projeto: soluções reutilizáveis de software orientado a objetos; tradução de Luiz A. Meirelles Salgado.
Porto Alegre: Bookman, 2007.
• HEGODA, D. 2013. Why? When to? Software Design Patterns. Disponível em: http://dasunhegoda.com/software-design-
patterns/158/
• JAVACAMP. 2012. Java Design Patterns At a Glance. Disponível em: http://www.javacamp.org/designPattern/
• LEACOCK, M.; MALONE, E.; WHEELER, C. Implementing a Pattern Library in the Real World: A Yahoo! Case Study. In: Sixth Annual
ASIS&T Information Architecture Summit. Montréal, Quebec, Canada, mar. 2005. Disponível em: http://leacock.com/patterns/
• MCDONALD, J. 2007. Design Patterns Quick Reference. Disponível em: http://www.mcdonaldland.info/2007/11/28/40/
• MEMÓRIA, F. Design para a internet: Projetando a experiência perfeita. Rio de Janeiro: Elsevier, 2005.
• VINICIUS, G. 2011. Padrões de design orientado a objetos. Disponível em: http://pt.slideshare.net/glaucovinicius/padres-de-design-
orientado-a-objetos
• WELIE, M. V. 2008. Patterns in Interaction Design. Disponível em: http://www.welie.com/patterns/
21/02/2014 Design Patterns | Aula 1 | Prof.ª Esp. Talita Pagani 59