Aula 2 de Design Patterns da Pós-graduação em Engenharia de Software.

1. Especialização em Engenharia de Software
Prof.ª Esp. Talita Pagani
talita.cpb@gmail.com | @talitapagani
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
1

2. Informações gerais
1. Definição de Design Patterns
2. Design Patterns para softwares orientados a objetos
a.
b.
c.
3.
4.
5.
6.
Padrões de criação;
Padrões estruturais;
Padrões comportamentais;
Estudo de caso de Design Patterns;
Modelagem de software com auxílio de Design Patterns
Design Patterns para interfaces gráficas;
Design Patterns para mobile.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
2

3. Padrões de criação
• 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.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
3

4. Padrões de criação
• 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.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
4

5. Padrões de criação
• 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.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
5

6. Padrões de criação
•
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.
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
6

7. Padrões de criação
• 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.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
7

8. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
8

9. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
9

10. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
10

11. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
11

12. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
12

13. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
13

14. Padrões estruturais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
14

15. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
15

16. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
16

17. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
17

18. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
18

19. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
19

20. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
20

21. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
21

22. Padrões comportamentais
• 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 ifelse ou switch;
– Quando cada estado deve
agir de forma semelhante e
deve ser uma subclasse de
uma mesma superclass.
22/02/2014
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
22

23. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
23

24. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
24

25. Padrões comportamentais
• 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
Fonte: GAMMA, et al., 2007; MCDONALD, 2007;
JAVACAMP 2012, DOFACTORY, 2014.
,
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
25

26. Design Patterns para softwares orientados a objetos
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
22/02/2014
• Foco: algoritmos e atribuição de responsabilidades a
objetos
• Evita acoplamento forte a uma solução em particular
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
26

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

28. Design Patterns para softwares orientados a objetos
• Abstract Factory para um jogo
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
28

29. Tournament
Game
createMatch()
createStatistics()
TicTacToe
Chess
createMatch()
createStats()
createMatch()
createStats()
Match
TTTMatch
22/02/2014
Statistics
ChessMatch
TTTStats
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
ChessStats
29

30. Design Patterns para softwares orientados a objetos
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

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

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

33. Estudo de caso
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
33

34. Estudo de caso
• 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

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
35

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
36

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
37

38. Estudo de caso
Figura 2 - Diagrama de Classe depois de aplicar o Mediator.
Fonte: AMMAR, 2008.
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
38

39. Estudo de caso
• 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

40. Estudo de caso
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
40

41. Estudo de caso
• 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

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

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

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

45. Estudo de caso
Herança
Delegação
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
Delegação
45

46. 22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
46

47. Laboratório 1
• 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

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

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

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

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

52. Laboratório 1
22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
52

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

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

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

56. 22/02/2014
Design Patterns | Aula 2 | Prof.ª Esp. Talita Pagani
56

57. Tarefas
• 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

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

59. •
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-designpatterns/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-designorientado-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