Unidade 01 PADRÕES DE PROJETO DE SOFTWARE CCT0320 Cap 01 18 03 19 xx ppts 01 Slide por folha

Prévia do material em texto

1
PADRÕES DE PROJETO DE SOFTWARE ­ CCT0320
• Profª. Alex Casañas, M.Sc.
• brulex@bol.com.br
2
3
@brulex@brulex
@casanasdf@casanasdf
@sabadotec@sabadotec
4
Prof. M.Sc. Alex Casañas 
+55(61) 98413­0351 (OI) ou 98135­6407(WhatsApp e TIM)
­ SKYPE ­ casanasdf ­
Páginas oficiais:
Redes Sociais e Parcerias
Facebook: Brulex 
https://www.fb.com/alex.casanas.brulex.professor
LinkedIn: Brulex http://br.linkedin.com/in/brulex
Twitter: @brulex https://twitter.com/#!//casanasdf
Compre com Segurança Aqui ­ Parceria  entre o Professor Alex com 
o site Submarino desde 1999
http://www.submarino.com.br/menu/1060/Livros/?franq=131531
5
/alex.casanas.brulex.professor/in/brulex
casanasdfbrulex@bol.com.br
Contatos
t.me/ransomwarebr
t.me/cyberseguranca
6
REVISÃO 
Modelo pedagógico do curso – Prof. Alex Casañas
7 7
8
PADRÕES DE PROJETO DE SOFTWARE ­ CCT0320
Cronograma Parte Presencial
Motivações para estudo de Padrões; Introdução aos 
Padrões; Introdução; Classificação dos Padrões GoF; 
Classificação dos Padrões GRASP; Padrões de 
construção; Padrões Estruturas; Padrões 
comportamentais; Discussão sobre a utilização dos 
Padrões; Princípios de Projetos Orientados a Objetos.
.
9
10
Web+bibliografia
• GAMMA, Erich et AL. Design Patterns: Elements of 
Reuable Object­Oriented.Software. Rio de Janeiro: 
Addison­Wesley, 2002.
• GAMMA, Erich et AL. Padrões de Projeto. 1. ed. 
Porto Alegre: Artmed, 2000.
• LARMAN, C. Utilizando UML e padrões. 3. ed. Porto 
Alegre: Artmed, 2007.
11
Bibliografia
Utilizando UML e Padrões: uma introdução à análise e ao
projeto orientados a objetos - 3ª Edição
Autor: Larman, Craig
Padrões de Projeto: soluções reutilizáveis de software
orientado a objetos
Autor: Gamma, Erich ... [et al]
12
13
14
15
Web+bibliografia
• https://www.canalti.com.br/
• https://www.youtube.com/watch?v=QUZlbMJ
pbOg
• Workshop sobre Padrões – Prof Andre Baltieri
• Material do Prof. MSc.Vagner Figuerêdo
de Santana.
• Material pedagógico Estácio. 
16
17
Web+bibliografia
• 1. RUMBAUGH, J. Modelagem e projeto baseados em objetos. 6. ed. 
Rio de Janeiro: Campus, 1998.
• 2. ALUR, Deepak; CRUPI, John. Core J2EE Patterns: Best Practices and 
Design Strategies, ed. Prentice Hall, 2002.
• 3. LARMAN, C. Applying UML and Patterns, 2. ed. Prentice Hall, 2002.
• 4. Paula Filho, W. P., Engenharia de Software ­ fundamentos, métodos 
e padrões, 3 ed., LTC, 2009.
• 5. Metsker, S.J, Padrões de Projeto em Java, 1 ed. Artmed, 2004.
• https://brizeno.wordpress.com/padroes/
18
https://www.devmedia.com.br/
19
O que veremos nesta primeira aula
� Conhecer o conceito de padrão de projeto 
e a suas aplicações;
� Entender a descrição de um padrão de 
projeto e como usar;
� Conhecer as duas principais famílias de 
padrões de projeto que serão estudadas 
no decorrer da disciplina;
� Iniciar o estudo dos padrões de projeto da 
família GoF.
20
ETAPA#1
O que é o PADRÕES DE PROJETO DE 
SOFTWARE - CCT0320?
20
21
Questões para debate
• Banca: FCC Órgão: TRT ­ 14ª Região (RO e AC)
• Prova: Tecnologia da Informação
• Os padrões de projeto
• a) podem deixar um sistema mais complexo ou 
degradar a sua performance. O seu uso indevido ou 
inadequado para um determinado contexto 
constitui­se em um anti pattern.
22
Questões para debate
• b) sempre criam flexibilidade e variabilidade pela 
introdução de níveis adicionais de endereçamento 
indireto. Como melhoram o desempenho do 
sistema devem ser sempre aplicados.
• c) comportamentais abstraem ou adiam o processo 
de criação dos objetos, ajudando a tornar o sistema 
dependente de como seus objetos são criados, 
compostos e representados. 
•
23
Questões para debate
• d) estruturais se concentram nos algoritmos de 
herança entre os objetos. Eles não descrevem 
apenas padrões de objetos ou de classes, mas 
também os padrões de comunicação entre os 
objetos.
• e)de criação se preocupam com a forma como 
classes e objetos são compostos para formar 
estruturas maiores. Utilizam o polimorfismo para 
compor interfaces ou implementações.
24
Questões para debate
• Banca: FCC Órgão: TRT ­ 14ª Região (RO e AC)
• Prova: Tecnologia da Informação
• Os padrões de projeto
• a) podem deixar um sistema mais complexo ou 
degradar a sua performance. O seu uso indevido 
ou inadequado para um determinado contexto 
constitui­se em um anti pattern.
25
Explicação
• https://www.devmedia.com.br/conheca­os­padroes­de­projeto/957
• A. CORRETA: Em Engenharia de software, um anti­padrão é um padrão de projeto 
de software que pode ser comumente usado mas é ineficiente e/ou contra­
produtivo em prática.
• O termo foi cunhado em 1995 por Andrew Koenig, inspirado pelo livro do Gang of
Four Design Patterns, que desenvolveu o conceito de padrão de desenho de 
software. O termo foi largamente popularizado três anos depois pelo 
livro AntiPatterns, que estendeu o uso do termo além do campo de desenho de 
software para interações pessoais em 
geral. FONTE: https://www.wikiwand.com/pt/Antipadr%C3%B5es_de_projeto_de_
software 
26
Explicação
• B. ERRADA: nem sempre criam flexibilidade e variabilidade. Além disso a função dos padrões 
não é a melhoria do desempenho do sistema, mas a resolução de problemas comuns.
• C: ERRADA: São os padrões que estão preocupados com os algoritmos e as atribuições de 
responsabilidade entre objetos. Descrevem não só os padrões entre objetos ou classes, mas 
também os padrões de comunicação entre eles.
• D: ERRADA: Padrões de projeto estruturais são padrões que lidam com as estruturas do 
projeto, facilitando a comunicação entre suas entidades. Por enquanto, esse conceito 
permanecerá abstrato, mas de acordo com os padrões deste tipo, entenderemos melhor.
• E: ERRADA: Os padrões de criação descrevem as técnicas para instanciar objetos (ou grupos 
de objetos), e possibilitam organizar classes e objetos em estrutura maiores, os de 
comportamento se caracterizam pela maneira pelas quais classes ou objetos interagem e 
distribuem responsabilidades e os estruturais lidam com a composição de classes ou objetos. 
O segundo critério é o escopo ­ especifica se o padrão é aplicado à classe ou objeto.
27
Introdução
• Projetar software OO reusável e de boa qualidade é uma tarefa
difícil;
• Para realizar essa tarefa a contento, projetistas experientes usam
soluções de sucesso com as quais já trabalharam no passado;
• Isso leva à descoberta de padrões de projeto;
• Durante duas décadas, a comunidade de padrões vem se desenvolvendo
de acordo com essa dinâmica.
28
Porque usar Padrões?
• Programar é uma tarefa divertida para muitas
pessoas, no entanto desenvolver um software com
qualidade é uma atividade complexa. Entre ótimas
idéias, requisitos, visões e um produto de software
que funcione, existe muito mais do que simplesmente
programar (Larman, 2007).
29
30
Todas as arquiteturas orientadas a 
objeto possuem padrões?
• Em geral, todas as arquiteturas orientadas a objeto bem­
estruturadas estão cheias de “padrões”. Uma das maneiras de
medir a qualidade de um sistema orientado a objetos é avaliar se os
colaboradores tomaram bastante cuidado com as colaborações
comuns entre seus objetos. Focalizar em tais mecanismos durante o
desenvolvimento de um sistema pode levar a uma arquitetura
menor, mais simples, muito mais compreensível do que aquelas
produzidas quanto padrões são ignorados. (Gamma et al., 2000).
31
O que é um padrão?
• Maneira testada ou documentada de alcançar um objetivo qualquer;
• Padrões são comuns em várias áreas da engenharia;
• Design Patterns, ou Padrões de Projeto;
•Padrões para alcançar objetivos na engenhariade software usando
classes e métodos em linguagens orientadas a objeto;
•Inspirado em "A Pattern Language" de Christopher Alexander, sobre
padrões de arquitetura de cidades, casas e prédios;
•"Design Patterns" de Erich Gamma, John Vlissides, Ralph Jonhson e
Richard Helm, conhecidos como "The Gang of Four", ou GoF, descreve
23 padrões de projeto úteis
32
O que é um padrão?
"Cada padrão descreve um problema que ocorre repetidas vezes em nosso
ambiente, e então descreve o núcleo da solução para aquele problema, de
tal maneira que pode-se usar essa solução milhões de vezes sem nunca
fazê-la da mesma forma duas vezes"
Christopher Alexander, sobre padrões em Arquitetura
33
O que é um padrão?
"Os padrões de projeto são descrições de objetos que se comunicam e
classes que são customizadas para resolver um problema genérico de
design em um contexto específico"
Gamma, Helm, Vlissides & Johnson, sobre padrões em software
34
O que é um padrão?
“Um padrão é a abstração de uma forma concreta que ocorre muitas vezes
em contextos específicos.”
Riehle & Zullighoven, 1996
35
O que é um padrão?
“Resolve um problema. É um conceito provado. A solução não é óbvia.
Descreve um relacionamento.”
Jim Coplien, 1996
36
Padrões - características
• Capturam soluções de projeto exaustivamente refinadas com o passar
do tempo;
• São o resultado de um longo processo de projeto, re-projeto, teste e
reflexão sobre o que torna um sistema mais flexível, reusável e modular;
37
Catálogos de padrões
Um catálogo de padrões é um grupo de padrões que estão relacionados
de uma certa forma e podem ser usados juntos ou independentemente:
•Core JEE(Java Enterprise Edition);
•PoEAA(PatternsofEnterprise Application Architecture);
•POSA(Pattern-OrientedSoftware Architecture)
•GRASP(General Responsibility Assignment Software 
Patterns/Principles)
•GoF(Gang ofFour)
38
39
Quais são as famílias mais
relevantes?
• No decorrer desta disciplina, serão abordadas duas
grandes famílias de padrões de projeto.
• padrões GoF;
• padrões GRASP.
40
O que significa GOF?
• padrões GoF (do inglês, Gang of Four).
41
O que significa GRASP ?
• padrões GRASP (do inglês, General Responsibility
Assignment Software Patterns).
42
Mesmo não sendo desenvolverdor
preciso aprender padrões?
• Sim, isto lhe auxiliará em todas as etapas de
construção e reaproveitamento de código;
43
44
• https://www.youtube.com/watch?v=IwxEX62
9RsE
• Mostra o detalhamento dos padrões.
• Aula 1044 ­ Design Patterns ­ Video #1 ­ Como 
surgiram os padrões de projeto 12m15s
45
ETAPA#2
Histórico e Contextualização
45
46
Introdução
Um pouco de história
� Christopher Alexander
� A Pattern Language: Towns, Buildings, 
Constrution (1977);
� Gamma et al.
� Design Patterns: Elements of Reusable 
Object-Oriented Software (1994).
47
• Aula 1047 ­ Design Patterns ­ Video #1 ­ Como surgiram os padrões de projeto 
12m15s
• https://www.youtube.com/watch?v=sUyTKDHGCtA
48
49
50
Introdução
Um pouco de história
� Um padrão descreve
� problema que ocorre
repetidamente;
� solução para esse problema 
de forma que se possa 
reutilizar a solução.
51
Introdução
Por quê usar padrões?
� Aprender com a experiência dos outros;
� O jargão facilita a comunicação de princípios;
� Melhora a qualidade do software;
� Descreve abstrações de software;
� Ajuda a documentar a arquitetura;
� Captura as partes essenciais de forma 
compacta.
52
Introdução
No entanto, padrões…
� não apresentam uma solução exata;
� não resolvem todos os problemas de
Design;
� não é exclusivo de orientação a objetos.
53
http://vincehuston.org/dp/
54
http://gee.cs.oswego.edu/dl/ca/ca/ca.html
55
http://www.oracle.com/technetwork/java/index.html
56
Introdução
Como selecionar um padrão?
� Entenda as soluções;
� Estude o relacionamento entre os padrões;
� Estude as similaridades entre os padrões;
� Conheça as principais causas de retrabalho;
� Considere o que pode mudar.
57
58
59
60
61
62
ETAPA#3
Padrões GOF
62
63
O que significa GOF?
• padrões GoF (do inglês, Gang of Four).
• De acordo com o livro: "Padrões de Projeto: soluções 
reutilizáveis de software orientado a objetos", os padrões 
"GoF" são divididos em 23 tipos. Em função dessa grande 
quantidade de padrões, foi necessário classificá­los de 
acordo com as suas finalidades.
• São 3 as classificações/famílias:
64
Catálogo - GoF
65
66
67
Explicação
• São 23 padrões, temos os criacionais (5):
­ Abstract Factory;
­ Factory Method;
­ Builder;
­ Prototype;
­ Singleton.
68
Explicação
• São 23 padrões, Os estruturais (7):
­ Bridge;
­ Decorator;
­ Facade;
­ Flyweight;
­ Adapter;
­ Proxy;
­ Composite.
69
Explicação
• São 23 padrões, os comportamentais (11):
­ Chain of Responsability;
­ Command;
­ Visitor;
­ Observer;
­ Iterator;
­ Strategy;
­ Interpreter;
­ State;
­ Memento;
­ Mediator;
­ Template Method.
70
O que significa Padrões de criação?
• Padrões de criação: Os padrões de criação são aqueles que 
abstraem e ou adiam o processo criação dos objetos. Eles 
ajudam a tornar um sistema independente de como seus 
objetos são criados, compostos e representados. 
• Um padrão de criação de classe usa a herança para variar a 
classe que é instanciada, enquanto que um padrão de 
criação de objeto delegará a instanciação para outro 
objeto. 
71
O que significa “herança”?
• Herança é um princípio de orientação a objetos, que 
permite que classes compartilhem atributos e métodos, 
através de "heranças". Ela é usada na intenção de 
reaproveitar código ou comportamento generalizado ou 
especializar operações ou atributos.
Aula 1071 ­ Herança na programação orientada a objetos 5m27s
https://www.youtube.com/watch?v=eHOZFMA9uKs
72
O que significa “herança”?
• Como exemplo pode­se observar as classes 'aluno' e 
'professor', onde ambas possuem atributos como nome, 
endereço e telefone. Nesse caso pode­se criar uma nova 
classe chamada por exemplo, 'pessoa', que contenha as 
semelhanças entre as duas classes, fazendo com que aluno 
e professor herdem as características de pessoa, desta 
maneira pode­ se dizer que aluno e professor são 
subclasses de pessoa.
73
https://www.caelum.com.br/apostila­java­orientacao­objetos/heranca­
reescrita­e­polimorfismo/#repetindo­cdigo
74
75
O que significa “instância(classe)”?
• Em programação orientada a objetos, chama­
se instância de uma classe, um objeto cujo comportamento 
e estado são definidos pela classe. "Instância" é, neste 
caso, um anglicismo, significando "caso" ou "exemplo" 
(em inglês instance).
• Por exemplo: "animal" é uma classe ou um molde; 
"cachorro" é uma instância de "animal" e apesar de 
carregar todas as características do molde de "animal“.
76
O que significa Padrões de criação?
• Padrões de criação: Os padrões de criação 
tornam­se importantes à medida que os 
sistemas evoluem no sentido de dependerem 
mais da composição de objetos do que a 
herança de classes. 
77
O que significa Padrões de criação?
• O desenvolvimento baseado na composição de objetos 
possibilita que os objetos sejam compostos sem a 
necessidade de expor o seu interior como acontece na 
herança de classe, o que possibilita a definição do 
comportamento dinamicamente e a ênfase desloca­se da 
codificação de maneira rígida de um conjunto fixo de 
comportamentos, para a definição de um conjunto menor 
de comportamentos que podem ser compostos em 
qualquer número para definir comportamentos mais 
complexos. 
78
O quesignifica Padrões de criação?
• Padrões de criação: Há dois temas recorrentes 
nesses padrões. Primeiro todos encapsulam 
conhecimento sobre quais classes concretas são 
usadas pelo sistema. Segundo ocultam o modo 
como essas classes são criadas e montadas. Tudo 
que o sistema sabe no geral sobre os objetos é que 
suas classes são definidas por classes abstratas. 
79
O que significa Padrões de criação?
• Conseqüentemente, os padrões de criação dão 
muita flexibilidade no que é criado, quem cria, 
como e quando é criado. Eles permitem configurar 
um sistema com objetos “produto” que variam 
amplamente em estrutura e funcionalidade. A 
configuração pode ser estática (isto é, especificada 
em tempo de compilação) ou dinâmica (em tempo 
de execução).
80
81
O que significa Padrões estruturais?
• Padrões estruturais: Os padrões estruturais se preocupam com a 
forma como classes e objetos são compostos para formar estruturas 
maiores. Os de classes utilizam a herança para compor interfaces ou 
implementações, e os de objeto ao invés de compor interfaces ou 
implementações, eles descrevem maneiras de compor objetos para 
obter novas funcionalidades. A flexibilidade obtida pela composição 
de objetos provém da capacidade de mudar a composição em 
tempo de execução o que não é possível com a composição estática 
(herança de classes).
82
83
O que significa Padrões comportamentais?
• Padrões comportamentais: Os padrões de 
comportamento se concentram nos algoritmos e 
atribuições de responsabilidades entre os objetos. 
Eles não descrevem apenas padrões de objetos ou 
de classes, mas também os padrões de 
comunicação entre os objetos. 
84
O que significa Padrões comportamentais?
• Os padrões comportamentais de classes utilizam a 
herança para distribuir o comportamento entre 
classes, e os padrões de comportamento de objeto 
utilizam a composição de objetos em contrapartida 
a herança. Alguns descrevem como grupos de 
objetos cooperam para a execução de uma tarefa 
que não poderia ser executada por um objeto 
sozinho.
85
86
87
88
Por que aprender padrões?
Aprender com a experiência dos outros
•Identificar problemas comuns em engenharia de software e utilizar soluções testadas e
bem documentadas;
•Utilizar soluções que têm um nome: facilita a comunicação, compreensão e
documentação;
Aprender a programar bem com orientação a objetos
•Os 23 padrões de projeto "clássicos" utilizam as melhores práticas em OO para atingir os
resultados desejados;
Desenvolver software de melhor qualidade
•Os padrões utilizam eficientemente polimorfismo, herança, modularidade, composição,
abstração para construir código reutilizável, eficiente, de alta coesão e baixo
acoplamento.
89
Elementos de um padrão
•Nome
•Problema:
•Quando aplicar o padrão, em que condições?
•Solução:
•Descrição abstrata de um problema e como usar os elementos 
disponíveis (classes e objetos) para solucioná-lo;
•Consequências:
•Custos e benefícios de se aplicar o padrão
•Impacto na flexibilidade, extensibilidade, portabilidade e 
eficiência do sistema.
90
Formas de classificação
Gamma et al [1] os classifica de duas formas
•Por propósito:
•criação de classes e objetos,
•alteração da estrutura de um programa,
•controle do seu comportamento.
•Por escopo: classe ou objeto.
Metsker [2] os classifica em 5 grupos, por intenção (problema a ser solucionado):
• oferecer uma interface,
• atribuir uma responsabilidade,
• realizar a construção de classes ou objetos,
• controlar formas de operação,
• implementar uma extensão para a aplicação.
91
Categorização por escopo
•Escopo de classe
•Descrevem relacionamentos entre classes e suas subclasses
(herança).
•Estáticos: relacionamentos são fixos e definidos em tempo de
compilação.
•Escopo de objeto
•Descrevem relacionamentos entre objetos.
•Dinâmicos: relacionamentos entre objetos podem ser alterados
em tempo de execução.
92
Categorização por finalidade
De criação
•Associados ao processo de criação de objetos;
•Tornam um sistema independente de como seus objetos são
criados, compostos e representados.
Comportamentais
•Têm a ver com a maneira pela qual responsabilidades são
distribuídas a classes e objetos durante a realização de uma
tarefa;
•São abstrações de aspectos comportamentais.
93
Categorização por finalidade
•Estruturais
•Tratam da composição de classes e objetos para formar estruturas
complexas;
•Associados à maneira como classes e objetos são organizados
estruturalmente;
•Oferecem formas efetivas para usar conceitos OO como herança e
composição;
•São abstrações de aspectos estruturais.
94
95
96
Resumo do padrões GoF
1. Adapter: Converter a interface de uma classe em outra interface
esperada pelos clientes.
2. Façade: Oferecer uma interface única de nível mais elevado para
um conjunto de interfaces de um subsistema.
3. Composite: Permitir o tratamento de objetos individuais e
composições hierárquicas desses objetos de maneira uniforme.
4. Bridge: Desacoplar uma abstração de sua implementação, de tal
forma que os dois possam variar independentemente.
5. Singleton: Garantir que uma classe só tenha uma única instância, e
prover um ponto de acesso global a ela.
97
Resumo do padrões GoF
6. Observer: Definir uma dependência um-para-muitos entre objetos
para que, quando um objeto mudar de estado, os seus dependentes
sejam notificados e atualizados.
7. Mediator: Definir um objeto que encapsula a forma como um
conjunto de objetos interage.
8. Proxy: Prover um substituto ou ponto através do qual um objeto
possa controlar o acesso a outro.
9. Chain of Responsibility: Compor objetos em cascata para, através
dela, delegar uma requisição até que um objeto a sirva.
98
Resumo do padrões GoF
10. Flyweight: Usar compartilhamento para suportar eficientemente
grandes quantidades de objetos complexos.
11. Builder: Separar a construção de objeto complexo da representação
para criar representações diferentes com mesmo processo.
12. Factory Method: Definir uma interface para criar um objeto mas
deixar que subclasses decidam que classe instanciar.
13. Abstract Factory: Prover interface para criar famílias de objetos
relacionados ou dependentes sem especificar suas classes
concretas.
99
Resumo do padrões GoF
14. Prototype: Especificar tipos a criar usando uma instância como
protótipo e criar novos objetos ao copiar este protótipo.
15. Memento: Externalizar o estado interno de um objeto para que o
objeto possa ter esse estado restaurado posteriormente.
16. TemplateMethod: Definir o esqueleto de um algoritmo dentro de
uma operação, deixando alguns passos a serem preenchidos pelas
subclasses.
17. State: Permitir a um objeto alterar o seu comportamento quando o
seu estado interno mudar.
100
Resumo do padrões GoF
18. Strategy: Definir uma família de algoritmos, encapsular cada um, e fazê-los
intercambiáveis.
19. Command: Encapsular uma requisição como objeto, para parametrizar clientes
com diferentes requisições, filas e dar suporte a ações reversíveis.
20. Interpreter: Dada uma linguagem, definir uma representação para sua
gramática junto com um interpretador.
21. Decorator: Anexar responsabilidades adicionais a um objeto dinamicamente
22. Iterator: Prover acesso sequencial a elementos de um objeto agregado, sem
expor sua representação interna.
23. Visitor: Representar uma operação a ser realizada sobre os elementos de uma
estrutura de objetos.
101
Classificação dos padrões GoF segundo Metsker [2]
102
GoF – Criacionais (Capítulo 3)
10
2
� Singleton;
� Factory Method;
� Abstract Factory;
� Prototype;
� Builder.
103
GoF – Criacionais
Singleton
� Intenção: Garantir que uma classe tenhasomente uma instância e fornecer um ponto de 
acesso à instância.
104
GoF – Criacionais
Singleton
� Estrutura:
<<singleton>> 
Class A
- static instance : Class A
- Class A()
+ static getInstance() : Class A
Client
105
GoF – Criacionais
Singleton
� Exemplo:
class Singleton{
private static Singleton instance; 
private Singleton{ }
public static Singleton getInstance(){ if( 
instance == null )
instance = new Singleton(); 
return instance;
}
}
106
GoF – Criacionais
Singleton
� Use quando:
�Deve haver exatamente uma instância da classe;
�Deve deve ser facilmente acessível aos clientes em 
um ponto de acesso bem conhecido.
Aula 1106 ­ Classe Singleton de Configuração ­ Mindset POO ­ Aula 10 10m12s
https://www.youtube.com/watch?v=AbhdjDbFUvI
https://brizeno.wordpress.com/2011/09/24/mao­na­massa­singleton/
107
GoF – Criacionais
Factory Method
� Intenção: Definir uma interface para 
criação de um objeto, mas deixar as 
subclasses decidirem qual classe
instanciar.
108
109
GoF – Criacionais
Factory Method
� Estrutura:
<<abstract>> 
Creator
+ factoryMethod()
<<abstract>>
<<abstract>> 
Product
ConcreteProductConcreteCreator
creates
+ factoryMethod()
110
GoF – Criacionais
Factory Method
� Exemplo:
abstract class Product{
...
}
class
...
}
ConcreteProductA extends Product{
class
...
ConcreteProductB extends Product{
}
111
GoF – Criacionais
Factory Method
� Exemplo:
abstract class Creator{
public abstract Product create();
}
class ConcreteCreatorA extends Creator{ 
public Product create(){
return new ConcreteProductA() ;
}
}
class ConcreteCreatorB extends Creator{ 
public Product create(){
return new ConcreteProductB() ;
}
}
112
GoF – Criacionais
Factory Method
� Exemplo:
class GoFTest{
public static void main( String a[] ){ 
Creator c ;
// If A is needed
c = new ConcreteCreatorA() ;
// else
c = new ConcreteCreatorB() ; 
Product p = c.create() ;
}
}
113
GoF – Criacionais
Factory Method
� Use quando:
�Uma classe não pode antecipar a classe de 
objetos que precisa criar;
�Uma classe deseja que suas subclasses 
especifiquem os objetos que cria.
114
Factory method
"Definir uma interface para criar um objeto mas deixar que subclasses
decidam que classe instanciar. Factory Method permite que uma classe
delegue a responsabilidade de instanciamento às subclasses."
[GoF]
115
Prós e contras
• Vantagens
• Criação de objetos é desacoplada do conhecimento do tipo concreto do
objeto
• Conecta hierarquias de classe paralelas
• Facilita a extensibilidade
• Desvantagens
• Ainda é preciso saber a classe concreta do criador de instâncias (pode-
se usar uma classe Factory, com método estático e parametrizado que
chame diretamente o Factory Method):
116
Exemplo 1
public class Montadora{
public void novoCarro(String tipo){
Carro carroZero;
if(tipo.equals(“Vectra”))
carroZero = new Vectra();
else
if(tipo.equals(“Omega”))
carroZero = new Omega();
else
if(tipo.equals(“Gol”))
carroZero = new Gol();
else
if(tipo.equals(“Golf”))
carroZero = new Golf();
}
};
Aula 1116 ­ Factory Method Pattern 8m46s 
https://www.youtube.com/watch?v=wQONM89Dlbg
https://brizeno.wordpress.com/2011/09/17/m
ao­na­massa­factory­method/
117
GoF – Criacionais
Abstract Factory
� Intenção: Fornecer interface para criação de 
famílias de objetos relacionados ou 
dependentes sem especificar suas classes
concretas.
118
119
120
121
• http://www.vincehuston.org/dp/
• http://www.vincehuston.org/dp/
• Exemplos de código em Java e C++
122
Continuação do Exemplo 1
123
GoF – Criacionais
Abstract Factory
� Estrutura:
<<abstract>>
AbstractFactory
+ createA() <<abstract>>
+ createB() <<abstract>>
ConcreteFactory1
+ createA()
+ createB()
ConcreteFactory2
+ createA()
+ createB()
124
GoF – Criacionais
Abstract Factory
� Use quando:
�Um sistema deveria ser independente de como 
seus produtos são criados, compostos e
representados;
�Um sistema deveria ser configurados com uma 
ou várias famílias de produtos;
�Uma família de objetos é destinada a ser 
usada de maneira única.
125
Abstract Factory
"Prover uma interface para criar famílias de objetos relacionados ou
dependentes sem especificar suas classes concretas."
[GoF]
126
Problema
127
Estrutura de Abstract Factory
128
Exemplo 1
https://brizeno.wordpress.com/2011/09/18/mao­na­massa­abstract­factory/
129
GoF – Criacionais
Prototype
� Intenção: Especificar os tipos de objetos a 
serem criados usando uma instância-
protótipo. Novos objetos são criados pela 
cópia desse protótipo(clones).
130
GoF – Criacionais
Prototype
� Estrutura:
Client Prototype
+ clone()
ConcretePrototype
+ clone()
+ op()
prototype -> clone()
return copy of self
131
GoF – Criacionais
Prototype
� Exemplo:
GraphicTool
Graphic
+ draw( coord )
+ clone()
Staff
+ draw( coord )
+ clone()
MusicalNote
+ draw( coord )
+ clone()
WholeNote
+ draw( coord )
+ clone()
HalfNote
+ draw( coord )
+ clone()
132
GoF – Criacionais
Prototype
� Use quando:
�Classes a instanciar são especificadas em tempo de
execução;
� Instâncias de classes podem ter poucas combinações de
estado.
Aula 1132 ­ Prototype Pattern Pattern 15m11s
https://www.youtube.com/watch?v=Wi_22Ol­n_c
https://brizeno.wordpress.com/2011/12/05/mao­na­massa­prototype/
133
GoF – Criacionais
Builder
� Intenção: Separar a construção de um objeto 
complexo de sua representação de modo que 
o mesmo processo de construção possa criar 
diferentes representações.
134
GoF – Criacionais
Builder
� Exemplo:
class Director{
...
private Builder b ;
b = new ConcreteBuilder() ; 
for( Object o : Collection )
b.buildPart( o ) ; Product p 
= b.getResult() ;
...
}
135
GoF – Criacionais
Builder
� Exemplo:
abstract class Builder{ abstract 
buildPart( Part p );
}
class ConcreteBuilder extends Builder{ 
public Part buildPart( PartA a ){...} 
public Part buildPart( PartB b ){...} 
public Product getResult(){...}
// Product of A&B is returned
}
136
GoF – Criacionais
Builder
� Use quando:
�O algoritmo para criar um objeto complexo deveria ser 
independente das partes que compõem o objeto
�O processo de construção deve permitir diferentes 
representações para o objeto que é construídos
Aula 1136 ­ Builder Pattern 9m32s
https://www.youtube.com/watch?v=7bZDPzF6RXw
https://brizeno.wordpress.com/2011/09/25/mao­na­massa­builder/
137
138
GoF – Criacionais (Capítulo 3)
�O que vimos até agora:
� Singleton(Responsabilidade);
� Factory Method(Contrução);
� Abstract Factory(Contrução);
� Prototype(Contrução);
� Builder(Contrução).
139
Classificação dos padrões GoF segundo Metsker [2]
140
GoF – Estruturais (Capítulo 4)
�O que iremos ver agora?
� Composite(interfaces);
� Decorator(estensões)
� Proxy (Responsabilidade);
� Adapter (interfaces);
� Bridge (interfaces);
� Facade (interfaces);
� Flyweight (Responsabilidade);
141
GoF – Estruturais
Composite
� Intenção: Compor objetos em estruturas 
de árvore para representarem hierarquias 
do tipo todo-parte.
142
GoF – Estruturais
Composite
� Estrutura:
Client
<<abstract>> 
Component
+ op()
+ add( :Component )
+ remove( :Component )
+ getChild( int )
Leaf
+ op()
Composite
+ op()
+ add( :Component )
+ remove( :Component )
+ getChild( int )
143
GoF – Estruturais
Composite
� Exemplo:
Client
<<abstract>>Component
+ op()
+ add( :Component )
+ remove( :Component )
+ getChild( int )
File
+ op()
Directory
*
+ op()
+ add( :Component )
+ remove( :Component )
+ getChild( int )
144
GoF – Estruturais
Composite
�Use quando:
�Você quer representar hierarquia de 
objetos do tipo parte-todo;
�Você quer que clientes tratem objetos 
compostos e individuais da mesma
forma.
Aula 1144 ­ Composite Pattern Implementando 7m47s 
https://www.youtube.com/watch?v=p0YPcMUppg8
https://brizeno.wordpress.com/2011/09/12/mao­na­massa­composite/
145
GoF – Estruturais
Decorator
� Intenção: Dinamicamente, agregar 
funcionalidades a um objeto.
146
GoF – Estruturais
Decorator
� Estrutura:
+ op()
Concrete
component.op()
<<abstract>> 
Component
+ op()
Component <<abstract>> 
Decorator
ConcreteDecoratorB
- addedState
+ op()
+ addedBehavior()
ConcreteDecoratorA
- addedState
+ op()
+ addedBehavior()
147
GoF – Estruturais Decorator
� Exemplo:
abstract class Decorator{
...
private Component component ; public 
Decorator( Component c ){
component = c ;
}
...
public void operation(){ 
component.operation() ;
}
}
148
GoF – Estruturais
Decorator
� Exemplo:
class GoFTest{
...
Component c = new ConcreteDecoratorA( new
ConcreteDecoratorB(
new ConcreteComponent())); 
c.operation();
...
}
149
GoF – Estruturais
Decorator
� Outro exemplo:
Sanduich s = new Hamburguer( new
Hamburguer(
new Letuce( new
Cheese(
new SpecialSpice( new
Onion(
new Pickles(
new BreadWithGergelim())))))));
150
GoF – Estruturais
Decorator
� Use quando:
�Deseja adicionar responsabilidades para objetos 
individuais dinamicamente, de maneira transparente e 
sem afetar outros objetos;
�Quando uma hierarquia de subclasses não é prática devido 
ao grande número de possibilidades (explosão de classes).
Aula 1150 ­ Decorator Pattern 12m12s
https://www.youtube.com/watch?v=3_iV0hPlbKQ
https://brizeno.wordpress.com/2011/08/31/decorator/
151
GoF – Estruturais
Proxy
� Intenção: Fornecer um representante 
de um objeto para controlar o acesso 
ao mesmo.
152
GoF – Estruturais
Proxy
� Estrutura:
Client
Subject
+ request()
Proxy
+ request()
RealSubject
+ request()
Proxy.request() uses 
RealSubject.request()
15
2
153
GoF – Estruturais
Proxy
15
3
� Exemplo:
class RealSubject extends Subject{
...
public request(){
// implementation of the request
}
...
}
154
GoF – Estruturais
Proxy
� Exemplo:
class Proxy extends Subject{
...
public request(){
Subject s = new RealSubject() ; 
s.request() ;
}
...
}
155
GoF – Estruturais
Proxy
� Exemplo:
class GoFTest{
...
Subject s = new Proxy() ; 
s.request() ;
...
}
156
GoF – Estruturais
Proxy
�Use quando:
�Há a necessidade de uma referência 
sofisticada ou versátil a um objeto (mais do 
que um simples ponteiro).
Aula 1156 ­ Proxy Pattern Implementando 15m48s
https://www.youtube.com/watch?v=4YWtUT4MKtw
https://brizeno.wordpress.com/2011/10/01/mao­na­massa­proxy/
157
GoF – Estruturais
Adapter
� Intenção: Converter a interface de uma 
classe em outra que os clientes
esperam.
158
GoF – Estruturais
Adapter
� Estrutura (class adapter):
Client
Adapter
+ request()
<<abstract>> 
Target
+ request()
Adaptee
+ specificRequest()
specificRequest()
159
GoF – Estruturais
Adapter
� Estrutura (object adapter):
Client
Adapter
+ request()
<<abstract>> 
Target
+ request()
Adaptee
+ specificRequest()
adaptee.specificRequest()
160
GoF – Estruturais
Adapter
�Exemplo (object adapter):
abstract class Target{
public abstract void request();
}
class Adapter extends Target{ 
public void request(){
Adaptee a = new Adaptee();
a.specificRequest();
}
}
161
GoF – Estruturais
Adapter
� Use quando:
�Deseja usar uma classe existente, mas sua interface não 
combina com o que precisa;
� Você precisa criar classes reutilizáveis que cooperem com 
classes não previstas.
Aula 1161 ­ Adapter Pattern 16m10s
https://www.youtube.com/watch?v=xa9WDIM4yxs
https://brizeno.wordpress.com/2011/10/03/mao­na­massa­adapter/
162
GoF – Estruturais
Facade
�Intenção: Fornecer uma interface 
unificada para um conjunto de 
interfaces de um subsistema.
163
GoF – Estruturais
Facade
� Estrutura:
Façade
subsystem classes
164
GoF – Estruturais Facade
� Exemplo:
class Facade{
public Response parseRequest( Request r ){
RequestController rc;
rc = RequestController.getInstance(); return 
rc.parse( r );
}
public boolean areYouAlive(){ 
SystemController sc ;
sc = SystemController.getInstance() ; return
sc.isAlive();
}
}
165
GoF – Estruturais Facade
� Use quando:
� Precisar de uma interface simples para um subsistema
complexo;
�Há muitas dependências entre clientes e classes de 
implementações de uma abstração
�Desejar dividir seu sistema em camadas.
Aula 1165 - Façade Pattern Implementando 10m27s
https://www.youtube.com/watch?v=lrODwcK-
CgQ&list=PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O7hR&index=14
https://brizeno.wordpress.com/2011/11/17/mao­na­massa­facade/
166
GoF – Estruturais ­ Bridge
� Intenção: Desacoplar uma abstração de sua 
implementação, de modo que as duas possam 
variar independentemente.
167
GoF – Estruturais ­ Bridge
� Antes de falar do problema é preciso dizer que 
este padrão é bem parecido com o Factory
Method e o Abstract Factory, então vamos 
analisar o mesmo exemplo para ver melhor as 
diferenças e semelhanças entre eles.
168
GoF – Estruturais ­ Bridge
O problema é que precisamos modelar um sistema de 
venda de carros para uma concessionária. Queremos 
que o sistema seja flexível, para adição de novos 
carros, e de fácil manutenção. Vimos que com os 
padrões Factory Methode o Abstract Factory podemos 
alcançar este resultado de maneira bem simples.
169
GoF – Estruturais ­ Bridge
O problema é que precisamos modelar um sistema de 
venda de carros para uma concessionária. Queremos 
que o sistema seja flexível, para adição de novos 
carros, e de fácil manutenção. Vimos que com os 
padrões Factory Methode o Abstract Factory podemos 
alcançar este resultado de maneira bem simples.
https://brizeno.wordpress.com/2011/09/25/mao­na­
massa­builder/
170
GoF – Estruturais ­ Bridge
O problema é que precisamos modelar um sistema de 
venda de carros para uma concessionária. Queremos 
que o sistema seja flexível, para adição de novos 
carros, e de fácil manutenção. Vimos que com os 
padrões Factory Methode o Abstract Factory podemos 
alcançar este resultado de maneira bem simples.
https://brizeno.wordpress.com/2011/09/25/mao­na­
massa­builder/
171
RefinedAbstraction
+ operation()
GoF – Estruturais
Bridge
� Estrutura:
Client
<<abstract>> 
Implementor
+ operationImpl ()
ImplementorA
+ operationImpl ()
ImplementorB
+ operationImpl ()
<<abstract>> 
Abstraction
+ operation()
172
RefinedAbstraction
+ drawRect()
GoF – Estruturais
Bridge
� Exemplo:
Client
<<abstract>> 
WindowImpl
+ devDrawLine ()
XWindowImpl
+ devDrawLine ()
PMManager
+ devDrawLine ()
<<abstract>> 
Window
+ drawRect()
imp.devDrawLine()
imp.devDrawLine()
imp.devDrawLine()
imp.devDrawLine()
173
174
GoF – Estruturais
Bridge
�Use quando:
�Deseja evitar acoplamento permanente entre 
abstração e sua implementação;
�Abstração e implementação devem ser 
extensíveis;
�Mudanças na implementação não devem ter 
impactos nos clientes que usam a abstração.
https://brizeno.wordpress.com/2011/10/13/mao­na­massa­bridge/175
O termo “Acoplamento”?
• Em engenharia de software, acoplamento ou dependência
• é o grau em que um módulo depende de outros módulos 
de programação.
• Modularização em tecnologia da informação é um conceito
onde o sistema ou software é dividido em partes distintas.
Compõe o ferramental necessário para um programa mais
legível com uma melhor manutenção e melhor
desempenho por meio da programação estruturada.
176
https://github.com/casanasdf/Padr­es­de­Projeto
• Neste repositório existem exemplos de utilização de 
Padrões de Projeto documentados pela Gangue dos 
Quatro implementados em Java.
• Para saber mais informações sobre os problemas 
abordados em cada um dos projetos 
acesse: brizeno.wordpress.com/padroes
177
178
GoF – Estruturais
Flyweight
� Intenção: Usar compartilhamento para suportar 
eficientemente grandes quantidades de objetos com 
granularidade fina.
179
GoF – Estruturais
Flyweight
� Estrutura:
Client
FlyweightFactory
+ getFlyweight(key)
Flyweight
+ operation(extrinsicState)
ConcreteFlyweight
- intrinsicState
+ operation(extrinsicState)
UnsharedConcreteFlwweight
- allState
+ operation(extrinsicState)
if( flyweight[key] exists){ 
return flyweight[key]
} else {
create new flyweight;
add it to pool of flyweight; 
return the new flyweight
}
180
GoF – Estruturais
Flyweight
� Exemplo:
class FlyweightFactory{ private 
Flyweight pool[];
public Flyweight getFlyweight(int key)
{
if( pool[ key ] != null ){ 
pool[key] =
new ConcreteFlyweight();
}
return pool[key] ;
}
}
181
GoF – Estruturais
Flyweight
� Exemplo:
class GoFTest{
...
private fc FlyweightFactory; fc
= new FlyweightFactory();
Flyweight f =
fc.getFlyweight( Flyweight.A ); 
f.operation( newState ) ; f.run();
...
}
182
GoF – Estruturais
Flyweight
�Use quando todos estes forem verdade:
�Uma aplicação usa um grande número de
objetos;
�Custo de armazenagem é alto (muitos
objetos);
�Boa parte do estado do objeto pode ser
extrínseca;
183
GoF – Estruturais
Flyweight
� Use quando todos estes forem verdade:
�Muitos grupos de objetos podem ser trocados por 
relativamente poucos objetos quando a parte 
extrínseca é removida;
�A aplicação não depende da identidade dos 
objetos, uma vez que serão compartilhados.
Aula 1183 ­ Flyweight e aplicação em jogos 8m04s
https://www.youtube.com/watch?v=qUtUXnu6yB0
https://brizeno.wordpress.com/2011/11/13/mao­na­massa­flyweight/
184
185
Classificação dos padrões GoF segundo Metsker [2]
186
GoF – Estruturais (Capítulo 4)
�O que vimos até agora:
� Composite(interfaces);
� Decorator(estensões)
� Proxy (responsabilidade);
� Adapter (interfaces);
� Bridge (interfaces);
� Facade (interfaces);
� Flyweight (responsabilidade);
187
GoF – Comportamentais 
(Capítulo 5)
� O que veremos agora:
� Template method (operações);
� Interpreter (operações);
� Mediator (responsabilidade);
� Chain of responsibility (responsabilidade);
� Observer (responsabilidade);
188
GoF – Comportamentais 
(Capítulo 5)
� State (operações);
� Strategy (operações);
� Command (operações);
� Memento (construção);
� Iterator (extensões);
� Visitor (extensões).
189
GoF – Comportamentais
Template Method
� Intenção:
�Definir o esqueleto de um algoritmo postergando
alguns passos para as subclasses;
� As subclasses podem redefinir certos passos de um 
algoritmo sem mudar sua estrutura.
190
GoF – Comportamentais
Template Method
� Estrutura: <<abstract>>
AbstractClass
+ templateMethod()
+ op1() <<abs>>
+ op2() <<abs>>
ConcreteClass
+ op1()
+ op2()
public void templateMethod(){
...
op1()
...
op2()
...
}
191
GoF – Comportamentais
Template Method
�Exemplo:
<<abstract>>
Clusterer
+ doCluster( o )
+ getDistance( o )
+ updateCentroids()
EuclideanClusterer
+ getDistance()
+ updateCentroid()
public void doCluster( Object o ){
...
// for all the objects
d = getDistance( o ) ;
// add to the closest cluster’s centroid
...
// after setting clusters to all objects 
updateCentroids() ;
...
// do it untill centroids don’t change
}
Abstract methods
192
GoF – Comportamentais
Template Method
� Use quando:
�Deseja implementar partes invariantes de um algoritmo 
uma vez e deixar que subclasses implementem o 
comportamento que pode variar;
�Um comportamento comum de subclasses pode ser
divido e colocado em uma classe comum para evitar
duplicação de código;
�Desejar controlar extensão de subclasses.
193
GoF – Comportamentais
Template Method
� Use quando:
� https://brizeno.wordpress.com/2011/09/18/mao-na-
massa-template-method/
� Aula 1193 – Template method 8m04s
� https://www.youtube.com/watch?v=vFdwKnPf8Fw&lis
t=PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O7hR&ind
ex=9
194
GoF – Comportamentais
Interpreter
� Intenção: Dada uma linguagem, definir 
uma representação para sua gramática 
juntamente com um interpretador que usa 
a representação para interpretar 
sentenças na linguagem.
195
GoF – Comportamentais
Interpreter
� Estrutura:
Client
TerminalEx
+ interpret(Context)
<<abstract>> 
Expression
+ interpret(Context)
pression NonterminalExpressionContext
+ interpret(Context)
196
GoF – Comportamentais
Interpreter
� Exemplo:
Client
NumberExp
+ interpret(Context)
<<abstract>> 
SpreadSheetExpression
+ interpret(Context)
ression CellExpressionContext
+ interpret(Context)
197
GoF – Comportamentais
Interpreter
�Use quando:
�Há uma gramática para interpretar e você pode 
representar sentenças dessa linguagem como 
árvores abstratas de sintaxe;
�Funciona melhor quando
�A gramática é simples;
�Eficiência não é um ponto crítico.
198
GoF – Comportamentais
Interpreter
� Use quando:
� https://brizeno.wordpress.com/2011/11/19/mao-na-
massa-interpreter/
� Vídeo em Inglês; 
� Aula 1193 - Interpreter Patters 15m46s - Inglês
� https://www.youtube.com/watch?v=IU-4NG-XGhg
199
GoF – Comportamentais
Mediator
� Intenção:
�Definir um objeto que encapsula a forma como 
um conjunto de objetos interage;
�Promove o baixo acoplamento evitando que objetos 
façam referência a outros explicitamente.
200
GoF – Comportamentais
Mediator
� Estrutura:
<<abstract>> 
Colleague
<<abstract>> 
Mediator
ConcreteMediator ConcreteColleagueA ConcreteColleagueB
201
GoF – Comportamentais
Mediator� Exemplo:
<<abstract>> 
UIComponent
SuggestionsList TextFieldConcreteMediator
<<abstract>> 
Mediator
+ propagate( UIComponent )
+ propagate( UIComponent ) + setList( String )+ getSelection()
+ setText( String )
+ getText()
+ changed()
mediator.propagate( this )
202
GoF – Comportamentais
Mediator
� Use quando:
�Objetos se comunicam de maneira bem definida, mas
complexa;
�Um objeto tem reúso restrito pois se comunica e 
referencia muitos objetos;
�Um comportamento que é distribuído entre várias classes 
deveria ser customizável sem utilizar muita herança.
203
GoF – Comportamentais
Mediator
� Use quando:
https://brizeno.wordpress.com/2011/10/26/mao­na­massa­
mediator/
Aula 1203 ­ MEDIATOR Padrões de Projeto ­ 5m30s
https://www.youtube.com/watch?v=K3S4XFEJ5o0
204
GoF – Comportamentais
Chain of
Responsibility
� Intenção:
�Evitar acoplamento entre remetente e destinatário 
de um pedido, dando a mais de um objeto a chance 
de responder um pedido;
�Encadeia objetos e passa request até que um deles 
responda.
205
GoF – Comportamentais
Chain of Responsibility
� Estrutura:
Client
ConcreteHandler1
+ handleRequest()
ConcreteHandler2
+ handleRequest()Handler
- successor
+ handleRequest()
if can handle request{ 
handle request
} else { 
successor.handleRequest()
}
206
GoF – Comportamentais
Chain of Responsibility
� Exemplo:
Client
MouseLogger
+ log( Event )
KeyPressLogger
+ log( Event )
EventLogger
- successor
+ log( Event )
if can log Event{ 
log Event data
} else {
successor.log( Event )
}
207
GoF – Comportamentais
Chain of Responsibility
Use quando:
�Mais de um objeto pode manipular uma requisição e o 
handler(sub­rotina, manipuladoras de eventos ) não é 
conhecido de antemão. O handler deveria ser associado
automaticamente;
� Você quer enviar uma requisição para vários objetos sem 
especificar o destinatário explicitamente;
�O conjunto de objetos que pode manipular uma requisição 
pode ser especificado dinamicamente.
208
GoF – Comportamentais
Chain of Responsibility
Use quando:
https://brizeno.wordpress.com/2011/11/09/mao-na-
massa-chain-of-responsibility/
Aula 1208 - Chain of Responsibility - exemplo -
5m30s
https://www.youtube.com/watch?v=aJQnG_f1ywA
209
GoF – Comportamentais
Observer
� Intenção: Define uma interdependência 1 para 
n entre objetos, de forma que quando um objeto 
muda de estado, todos os seus dependentes 
são notificados e atualizados.
210
GoF – Comportamentais
Observer
� Exemplo:
class ConcreteSubject extends Subject{ 
private List<Observer> observers ; //N 
private State state ;
...
public void attach( Observer o ){ 
o.setSubject( this ) ; 
observers.add( o ) ;
}
... (continua)
211
GoF – Comportamentais
Observer
� Exemplo:
public void detach( Observer o ){ 
o.setSubject( null ) ; 
observers.remove( o ) ;
}
public void notify(){
// i is iterator of observers list 
while(i.hasNext()){
Observer o = i.next() ; 
o.update() ;
}
}
}
212
GoF – Comportamentais
Observer
� Exemplo:
class ConcreteObserver extends Observer{ 
private Subject subject ; //1
private State state ;
...
public void setSubject( Subject s ){ 
subject = s ;
}
public void update(){
state = subject.getState() ;
}
}
213
GoF – Comportamentais
Observer
� Exemplo:
class GoFTest{
...
public static void main( String args[] ){
// 1 ‘source’
Subject s = new ConcreteSubject() ;
// N dependents
Observer o1 = new ConcreteObserver() ; 
s.attach( o1 ) ;
Observer o2 = new ConcreteObserver() ; 
s.attach( o2 ) ;
...
}
}
214
GoF – Comportamentais
Observer� Use quando:
�Uma abstração tiver dois aspectos, um dependente do 
outro. Encapsular esses aspectos em objetos
separados possibilita reusá-los independentemente;
�Uma mudança 1:n ocorre e você não sabe quantos 
objetos precisam ser alterados;
�Um objeto precisa notificar outros objetos sem fazer 
suposições sobre quem eles são.
215
GoF – Comportamentais
Observer
� Considerando o sensor de um radar de 
velocidade, o que é mais adequado 
Mediator ou Observer?
<<colleague>> 
Sensor
<<colleague>> 
Camera
<<colleague>> 
Display
Mediator
<<subject>> 
Sensor
<<observer>> 
Camera
<<observer>> 
Display
216
GoF – Comportamentais
Observer
� https://brizeno.wordpress.com/2011/10/17/mao-na-massa
observer/
� Aula 1216 - Observer Pattern Padrão de Projeto 11m10s 
� https://www.youtube.com/watch?v=1Hv-
XwzVkrU&list=PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O
7hR&index=5
217
GoF – Comportamentais
State
217
� Intenção: Permite a um objeto alterar seu 
comportamento quando seu estado interno muda. 
O objeto parecerá ter “mudado de classe”.
218
GoF – Comportamentais
State
� Estrutura:
<<abstract>> 
State
+ handle ()
ConcreteStateA
+ handle ()
ConcreteStateB
+ handle()
Context
+ request()
state.handle()
218
219
GoF – Comportamentais
State
219
�Exemplo:
class Sensor{
private State state ; public 
setState( State s ){
state = s ;
}
public int trackSpeed(){ return 
state.handle( this ) ;
}
}
220
GoF – Comportamentais
State
� Exemplo:
abstract class State{
abstract void handle( Sensor s ) ;
}
class CarPassing extends State{ public 
int handle( Sensor s ){
int speed = s.getSpeed() ; s.setState( 
new NoCarPassing() ); return speed ;
}
}
221
GoF – Comportamentais
State
� Use quando:
�O comportamento de um objeto depende do seu estado 
ele deve mudá-lo em tempo de execução;
�Operações tem vários fluxos condicionais que dependem 
do estado do objeto. State coloca cada um desses fluxos 
em uma classe separada.
222
GoF – Comportamentais
State
� Use quando:
� https://brizeno.wordpress.com/2011/11/21/mao-na-
massa-state/
� Aula 1222 - State Pattern Implementando 11m12s
� https://www.youtube.com/watch?v=DS0puoKlojw&l
ist=PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O7hR
&index=15
223
GoF – Comportamentais
Strategy
� Intenção:
�Define uma família de algoritmos, encapsula cada um 
deles e os torna intercambiáveis;
� Strategy permite que o algoritmo varie
independentemente dos clientes que a utilizam.
224
GoF – Comportamentais
Strategy
� Estrutura:
<<abstract>> 
Strategy
+ algorithm ()
ConcreteStrategyA
+ algorithm ()
ConcreteStrategyB
+ algorithm ()
Context
+ contextInterface()
strategy.algorithm()
225
GoF – Comportamentais
Strategy
� Exemplo:
<<abstract>> 
Sorter
+ sort ( List )
BubbleSorter
+ sort ( List )
MergeSorter
+ sort ( List )
Context
+ showList()
sorter.sort( List )
226
GoF – Comportamentais
Strategy
� Use quando:
� Várias classes relacionadas diferem somente no
comportamento;
� Precisa de variantes de um certo algoritmo;
�Um algoritmo usa dados que clientes não precisam ter
conhecimento;
�Uma classe define muitos comportamentos que aparecem 
em vários fluxos condicionais.
227
GoF – Comportamentais
Strategy
� Use quando:
� https://brizeno.wordpress.com/2011/08/31/strategy/
� Aula 1227 - Strategy Pattern Implementando 11m14s
� https://www.youtube.com/watch?v=noocoTJUV0Y&list=
PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O7hR&index=
11
228
GoF – Comportamentais
Command
� Intenção:
� Encapsular uma requisição em um objeto, 
permitindo:
� parametrizar clientes;
� enfileirar requisições;
� registrar requisições;
� suportar operações que podem ser desfeitas.
229
GoF – Comportamentais
Command
� Estrutura:
<<abstract>> 
Command
+ execute () <<abstract>>
Receiver
+ action ()
Invoker
Client
ConcreteCommand
- state
+ execute ()
230
GoF – Comportamentais
Command
� Exemplo:
<<abstract>> 
Command
+ execute () <<abstract>>
Document
+ delete ()
+ copy()
+ paste()
Application
DeleteCommand
- state
+ execute ()
Menu MenuItem
+ clicked()
command.execute() document.paste()
231
GoF – Comportamentais
Command
� Use quando:
� Desejar parametrizar objetos com base na ação a ser executada;
� Desejar especificar filas e executar solicitações em tempos diferentes;
� Desejar implementar “desfazer”;
� Desejar implementar logging(registro de eventos) de ações para serem 
reaplicadas em sistemas em caso de crash;
� Desejar estruturar um sistema em operações em alto nível construídas 
com base em operações.
232
GoF – Comportamentais
Command
� Use quando:
� https://brizeno.wordpress.com/2011/11/04/mao-na-massa-command/
� Aula 1232 - Command Pattern Padrão de Projeto 12m12s 
� https://www.youtube.com/watch?v=yBQOjvTc7zM&list=PLPUp6rbjBTHDe
hxG3dggOQ9V9EPm8O7hR&index=6
233
GoF – Comportamentais
Memento
� Intenção: Sem violar encapsulamento, capturar e 
externalizar o estado interno de um objeto de 
maneira que o objeto possa retornara esse estado 
mais tarde.
234
GoF – Comportamentais
Memento
� Estrutura:
CaretakerOriginator
- state
+ setMemento(Memento m)
+ createMemento()
Memento
- state
+ getState()
+ setState(State s)
return new Memento(state) state = m.getState()
235
GoF – Comportamentais
Memento
� Exemplo:
Ga
- state
+setCheckpoin
+createCheckp
return new Checkpoint(state) state = c.getState()
me Checkpoint
- state
t(Checkpoint c) + getState()
oint() + setState(State s)
CheckpointController
236
GoF – Comportamentais
Memento
� Use quando:
�Um snapshot de alguma parte do objeto precisa ser 
salva para que seja restaurada no futuro; e
�Uma interface direta para obter o estado expõe 
detalhes de implementação e quebraria o 
encapsulamento do objeto.
237
GoF – Comportamentais
Memento
� Use quando:
� https://brizeno.wordpress.com/2011/11/05/mao-na-massa-
memento/
� Aula 1237 - Memento Pattern Exemplo de implementação -
12m38s
� https://www.youtube.com/watch?v=KEddBJMSsms&list=PLP
Up6rbjBTHDehxG3dggOQ9V9EPm8O7hR&index=7
238
GoF – Comportamentais
Iterator
� Intenção: Fornecer um meio de acessar, 
sequencialmente, os elementos de uma 
agregação sem expor sua representação
interna.
239
GoF – Comportamentais Iterator
� Estrutura: <<abstract>> Iterator
+ first()
+ next()
+ isDone()
+ currentItem()
ConcreteIterator
Client
<<abstract>> 
Aggregate
+ createIterator()
ConcreteAggregate
+ createIterator() return new ConcreteIterator(this)
240
GoF – Comportamentais Iterator
� Exemplo: <<abstract>> Iterator
+ first()
+ next()
+ isDone()
+ currentItem()
BinaryTreeIterator
Client
<<abstract>> 
AbstractTree
+ createIterator()
BinaryTree
+ createIterator() return new BinaryTreeIterator(this)
241
GoF – Comportamentais
Iterator
� Use quando:
�Quiser acessar conteúdo de uma coleção de objetos sem 
expor sua representação interna;
�Quiser fornecer uma interface uniforme para navegar em 
diferentes estruturas de coleções de objetos (suportar 
iteração polimórfica).
242
GoF – Comportamentais
Iterator
� Use quando:
� https://brizeno.wordpress.com/2011/09/15/mao-na-massa-
iterator/
� Aula 1242 - Iterator Pattern Exemplo de implementação 
12m38s
� https://www.youtube.com/watch?v=wXGDRuXflnw&index=
8&list=PLPUp6rbjBTHDehxG3dggOQ9V9EPm8O7hR
243
GoF – Comportamentais
Visitor
� Intenção:
�Representar uma operação a ser executada 
nos elementos de uma estrutura de objetos.
�Visitor permite definir uma nova operação 
sem mudar a classe dos elementos sobre os 
quais opera.
244
GoF – Comportamentais
Visitor
� Estrutura:
<<abstract>> 
Visitor
+ visitElement(ConcreteElement)
ConcreteVisitor
Client
<<abstract>> 
Element
+ accept( Visitor )
ConcreteElement
+ accept ( Visitor v )
+ op() v.visitConcreteElement( this )
ObjectStructure
245
GoF – Comportamentais
Visitor
� Exemplo:
<<abstract>> 
Visitor
+ visitNode(ConcreteNode)
+ visitNode(OtherConcreteNode)
NodeVisitor
Client
<<abstract>> 
Node
+ accept( Visitor )
ConcreteNode
+ accept ( Visitor v )
Graph
+ op() v.visitNode( this )
246
GoF – Comportamentais Visitor
� Use quando:
� A estrutura de um objeto contém muitas classes de objetos 
com interfaces diferentes e você deseja realizar operações 
nesses objetos;
� Operações diferentes e não relacionadas precisam ser 
aplicadas em uma estrutura de objetos e você não deseja 
“poluí-los” com essas operações;
� Classes definindo estruturas raramente mudam, mas 
comumente você deseja definir novas operações nessa
estrutura.
247
GoF – Comportamentais Visitor
� Use quando:
� https://brizeno.wordpress.com/2011/11/26/mao-na-massa-
visitor/
� Padrões que utilizem estruturas de dados para 
representação podem utilizar o padrão Visitor, por exemplo, 
uma estrutura Composite ou Interpreter, pode oferecer um 
método de visita e atribuir para as classes visitantes a 
responsabilidade das operações sobre seu conjunto de 
dados.
248
GoF ­ Relacionamento entre padrões
Builder Iterator
Composite
Decorator
Flyweight
Visitor
Singleton Facade
Abstract Factory
Prototype
Factory Method
Template Method
Strategy
State Interpreter
Chain of Responsibility
Proxy
BridgeCommand
Memento Adapter
ObserverMediator
249
250
ETAPA#3
Questões para Debate
250
251
Questões para debate
• Banca: COPEVE Órgão: MPE­AL Prova: Analista
• Na literatura de engenharia de software, além dos 
padrões GRASP, é comum classificar os padrões de 
projeto em 3 tipos: padrões de criação, 
padrões estruturais e padrões
• a) comportamentais. b) de testes. 
• c) de implantação. d) de análise. 
• e) de visualização. 251
252
Questões para debate
• Banca: COPEVE Órgão: MPE­AL Prova: Analista
• Na literatura de engenharia de software, além dos 
padrões GRASP, é comum classificar os padrões de 
projeto em 3 tipos: padrões de criação, 
padrões estruturais e padrões
• a) comportamentais. b) de testes. 
• c) de implantação. d) de análise. 
• e) de visualização. 252
253
Explicação
254
Questões para debate
• Banca: FCC Órgão: TRT ­ 4ª REGIÃO Prova: Analista
• O catálogo de padrões de projeto (design patterns) 
do GoF contém
a) 20 padrões e está basicamente dividido em duas 
seções: Structural e Behavioral.
• b) 21 padrões e está basicamente dividido em duas 
seções: Creational e Behavioral.
• c)23 padrões e está basicamente dividido em duas 
seções: Structural e Behavioral.
255
Questões para debate
• d) 23 padrões e está, basicamente, dividido em três 
seções: Creational, Structural e Behavioral.
• e) 24 padrões e está basicamente dividido em três 
seções: Creational, Spectral e Behavioral.
256
Explicação
• São 23 padrões, temos os criacionais (5):
­ Abstract Factory
­ Factory Method
­ Builder
­ Prototype
­ Singleton
257
Explicação
• São 23 padrões, Os estruturais (7):
­ Bridge;
­ Decorator;
­ Facade;
­ Flyweight;
­ Adapter;
­ Proxy;
­ Composite.
258
Explicação
• São 23 padrões, os comportamentais (11):
­ Chain of Responsability;
­ Command;
­ Visitor;
­ Observer;
­ Iterator;
­ Strategy;
­ Interpreter;
­ State;
­ Memento;
­ Mediator;
­ Template Method.
259
Questões para debate
• Banca: FUMARC Órgão: PRODEMGE Prova: Analista 
• São padrões de projeto GoF (design 
patterns), EXCETO:
a) Strategy. 
• b) Workfow.
• c) Adapter.
• d)Facade.
260
Questões para debate
• Banca: FUMARC Órgão: PRODEMGE Prova: Analista 
• São padrões de projeto GoF (design 
patterns), EXCETO:
a) Strategy. 
• b) Workfow.
• c) Adapter.
• d)Facade.
261
Questões para debate
• Banca: FUMARC Órgão: PRODEMGE Prova: Analista 
• São padrões de projeto GoF (design 
patterns), EXCETO:
a) Strategy. 
• b) Workfow.
• c) Adapter.
• d)Facade.
262
Explicação
• Verificar a lista acima com os 23 tipos.
263
Questões para debate
• Banca: CESPE Órgão: TRT Prova: Tecnologia
• Considerando os padrões definidos pelo GoF (Gang of
Four), assinale a opção correta.
• a) O padrão chain of responsibility é responsável por 
manter a independência entre os objetos receptor e 
solicitante na orientação a objetos.
• b) O padrão flyweight é utilizado quando é desejável que 
uma interface (abstração) possa variar independentemente 
de suas implementações.
• c)
264
Questões para debate
• c) Os padrões GoF estão divididos nas categorias projetos 
de criação, projetos estruturais e projetos de transição.
• d) Os padrões abstract factory e singleton fazem parte da 
categoria projetosestruturais.
•
265
Explicação
• https://brizeno.wordpress.com/padroes/
266
Questões para debate
• Banca: INSTITUTO AOCP Órgão: MPE­BA Prova: Analista 
• Nos padrões GoF, o padrão Builder é constituído, 
dentre os seus elementos, do “builder” e “concrete
builder”. A diferença entre eles, respectivamente, 
é dada por qual alternativa?
• a) O primeiro especifica uma interface para um 
construtor de partes do objeto­produto, enquanto 
que o segundo constrói um objeto utilizando a 
interface do builder.
267
Questões para debate
• b) O primeiro constrói um objeto utilizando a interface do 
concrete builder, enquanto que o segundo especifica uma 
interface para um construtor de partes do objeto­produto.
• c) O primeiro especifica uma interface para um construtor 
de partes do objeto­produto, enquanto que o segundo 
define uma implementação da interface builder além de 
manter a representação que cria e fornece a interface para 
recuperação do produto.
268
Questões para debate
• d) O primeiro representa o objeto complexo acabado de 
construir e inclui classes que definem as partes 
constituintes, enquanto que o segundo especifica uma 
interface para um construtor de partes do objeto­produto.
• e) O primeiro define uma implementação da interface 
builder além de manter a representação que cria e fornece 
a interface para recuperação do produto, enquanto que o 
segundo representa o objeto complexo acabado de 
construir e inclui classes que definem as partes 
constituintes.
269
Questões para debate
• b) O primeiro constrói um objeto utilizando a interface do 
concrete builder, enquanto que o segundo especifica uma 
interface para um construtor de partes do objeto­produto.
• c) O primeiro especifica uma interface para um 
construtor de partes do objeto­produto, enquanto 
que o segundo define uma implementação da 
interface builder além de manter a representação 
que cria e fornece a interface para recuperação do 
produto.
270
Padrões de Projetos de Software
.
Dentre as alternativas abaixo identifique a que NÃO define uma situação
em que deve ser utilizado o padrão Factory Method?
a)Quando uma classe quer que suas subclasses especifiquem os
objetos criados.
b)Quando o algoritmo de criação de um objeto deve ser independente 
das suas partes constituintes e da maneira como ele é "montado".
c) Quando uma classe (o criador) não pode antecipar a classe dos
objetos que deve criar.
d)Quando se quer localizar num ponto único a conhecimento de qual 
subclasse está sendo usada.
e)Quando classes delegam responsabilidade para uma entre várias 
subclasses de apoio.
Questão 1
271
Padrões de Projetos de Software
.
Dentre as alternativas abaixo identifique a que NÃO define uma situação
em que deve ser utilizado o padrão Factory Method?
a)Quando uma classe quer que suas subclasses especifiquem os
objetos criados.
b)Quando o algoritmo de criação de um objeto deve ser independente 
das suas partes constituintes e da maneira como ele é "montado".
c) Quando uma classe (o criador) não pode antecipar a classe dos
objetos que deve criar.
d)Quando se quer localizar num ponto único a conhecimento de qual 
subclasse está sendo usada.
e)Quando classes delegam responsabilidade para uma entre várias 
subclasses de apoio.
Questão 1 – Resposta
272
Padrões de Projetos de Software
Considerando os padrões de Criação ou de Construção do GoF, analise o
modelo abaixo e em seguida marque a alternativa que define a representação.
a) MEDIATOR.
b) BUILDER.
c) FACADE.
d) SINGLETON.
e) FACTORY METHOD.
Questão 2
.
273
Padrões de Projetos de Software
Considerando os padrões de Criação ou de Construção do GoF, analise o
modelo abaixo e em seguida marque a alternativa que define a representação.
a) MEDIATOR.
b) BUILDER.
c) FACADE.
d) SINGLETON.
e) FACTORY METHOD.
Questão 2 – Resposta
.
274
Padrões de Projetos de Software
Considerando os padrões de Criação ou de Construção do GoF, analise o
modelo abaixo e em seguida marque a alternativa que define a representação.
a) Mediator.
b) Singleton.
c) Factory Method.
d) Facade.
e) Builder.
Questão 3
.
275
Padrões de Projetos de Software
Considerando os padrões de Criação ou de Construção do GoF, analise o
modelo abaixo e em seguida marque a alternativa que define a representação.
a) Mediator.
b) Singleton.
c) Factory Method.
d) Facade.
e) Builder.
Questão 3 – Resposta
.
276
Padrões de Projetos de Software
.
A família de padrões GoF é dividida em três grupos principais de padrões, a
saber:
a) Padrões de Criação; Padrões Metodológicos; Padrões de Ponte.
b) Padrões de Processo; Padrões de Singularidade; Padrões de Prototipação.
c) Padrões de Proxy; Padrões de Criação; Padrões de Encadeamento.
d) Padrões Estruturais; Padrões de Processo; Padrões de Responsabilidade.
e) Padrões Comportamentais; Padrões de Criação; Padrões Estruturais.
Questão 4
277
Padrões de Projetos de Software
.
A família de padrões GoF é dividida em três grupos principais de padrões, a
saber:
a) Padrões de Criação; Padrões Metodológicos; Padrões de Ponte.
b) Padrões de Processo; Padrões de Singularidade; Padrões de Prototipação.
c) Padrões de Proxy; Padrões de Criação; Padrões de Encadeamento.
d) Padrões Estruturais; Padrões de Processo; Padrões de Responsabilidade.
e) Padrões Comportamentais; Padrões de Criação; Padrões Estruturais.
Questão 4 – Resposta
278
Padrões de Projetos de Software
Baseando-se nas necessidades apresentadas do lado direito do quadro abaixo, 
relacione-as ao padrão adequado a utilização e, em seguida marque a 
alternativa que corresponde a sequência numerada correspondente.
a) 4 - 2 - 1 - 3
b) 4 - 3 - 1 - 2
c) 2 - 3 - 4 - 1
d) 4 - 1 - 2 - 3
e) 3 - 4 - 1 - 2
Questão 5
.
279
Padrões de Projetos de Software
Baseando-se nas necessidades apresentadas do lado direito do quadro abaixo, 
relacione-as ao padrão adequado a utilização e, em seguida marque a 
alternativa que corresponde a sequência numerada correspondente.
a) 4 - 2 - 1 - 3
b) 4 - 3 - 1 - 2
c) 2 - 3 - 4 - 1
d) 4 - 1 - 2 - 3
e) 3 - 4 - 1 - 2
Questão 5 – Resposta
.
280
Padrões de Projetos de Software
.
Ter uma baixa coesão nos objetos do sistema pode gerar difícil compreensão e 
reutilização, além de afetar a manutenibilidade. Nesse contexto, o que é ter baixa 
coesão?
Questão 6
281
Padrões de Projetos de Software
.
Ter uma baixa coesão nos objetos do sistema pode gerar difícil compreensão e 
reutilização, além de afetar a manutenibilidade. Nesse contexto, o que é ter baixa 
coesão?
É quando se tem uma mesma classe executando muitos trabalhos,
realizando muitas coisas não relacionadas.
Questão 6 – Resposta
282
Padrões de Projetos de Software
.
• Considere as seguintes assertivas sobre as vantagens do uso de Padrões de
• Projeto (Design Patterns):
I. Padrões de projeto proporcionam um vocabulário comum de projeto, facilitando comunicação, 
documentação e aprendizado dos sistemas de software.
II. Padrões de projeto auxiliam no desenvolvimento de software por meio da
• reutilização do projeto de soluções computacionais já testadas e aprovadas.
III. Uma biblioteca de padrões pode ajudar a melhorar e padronizar o desenvolvimento de
software.
• As assertivas corretas são:
a) somente I e III.
b) somente II e III.
c) somente I e II.
d) I, II e III.
e) somente II.
Questão 7
283
Padrões de Projetos de Software
.
• Considere as seguintes assertivas sobre as vantagens do uso de Padrões de
• Projeto (Design Patterns):
I. Padrões de projeto proporcionam um vocabulário comum de projeto, facilitando comunicação, 
documentação e aprendizado dos sistemas de software.II. Padrões de projeto auxiliam no desenvolvimento de software por meio da
• reutilização do projeto de soluções computacionais já testadas e aprovadas.
III. Uma biblioteca de padrões pode ajudar a melhorar e padronizar o desenvolvimento de
software.
• As assertivas corretas são:
a) somente I e III.
b) somente II e III.
c) somente I e II.
d) I, II e III.
e) somente II.
Questão 7
284
Padrões de Projetos de Software
.
O uso de classes "statics" garante que somente uma instância estará em 
memória e que a destruição pelo "garbage collection" será mais rápida do que o 
uso do padrão singleton. Por que então devemos usar o padrão singleton?
Questão 8
285
Padrões de Projetos de Software
.
O uso de classes "statics" garante que somente uma instância estará em 
memória e que a destruição pelo "garbage collection" será mais rápida do que o 
uso do padrão singleton. Por que então devemos usar o padrão singleton?
Porque uma classe static SEMPRE é carregada na memória quando a 
aplicação é executada e a classe SINGLETON não, sendo carregada na 
memória quando solicitada a primeira instância.
Questão 8 – Resposta
286
Padrões de Projetos de Software
.
Sobre padrões de projeto escolha a opção INCORRETA:
a)Padrões de projeto estão relacionados a diferentes níveis de abstração no 
desenvolvimento de aplicações orientadas a objetos, podendo aparecer ao longo de 
todo ciclo de análise e projeto de um sistema.
b)A diversidade de padrões disponíveis é bastante grande, pode-se ter, por 
exemplo, padrões arquiteturais, padrões de análise, padrões de projeto e 
padrões de código.
c)Cada padrão descreve um problema que ocorrem repetidas vezes em nosso 
ambiente e fornece o núcleo da solução para aquele problema, de tal maneira que 
se pode usar essa solução milhões de vezes sem nunca fazê-la da mesma forma.
d)Os padrões de projeto são descrições de objetos que se comunicam e classes que 
são customizadas para resolver um problema genérico de design em um contexto
específico.
e)Um padrão de projeto define uma estrutura que obrigatoriamente não poderá ser 
alterada pelo desenvolvedor.
Questão 9
287
Padrões de Projetos de Software
.
Sobre padrões de projeto escolha a opção INCORRETA:
a)Padrões de projeto estão relacionados a diferentes níveis de abstração no 
desenvolvimento de aplicações orientadas a objetos, podendo aparecer ao longo de 
todo ciclo de análise e projeto de um sistema.
b)A diversidade de padrões disponíveis é bastante grande, pode-se ter, por 
exemplo, padrões arquiteturais, padrões de análise, padrões de projeto e 
padrões de código.
c)Cada padrão descreve um problema que ocorrem repetidas vezes em nosso 
ambiente e fornece o núcleo da solução para aquele problema, de tal maneira que 
se pode usar essa solução milhões de vezes sem nunca fazê-la da mesma forma.
d)Os padrões de projeto são descrições de objetos que se comunicam e classes que 
são customizadas para resolver um problema genérico de design em um contexto
específico.
e)Um padrão de projeto define uma estrutura que obrigatoriamente não 
poderá ser alterada pelo desenvolvedor.
Questão 9
288
Padrões de Projetos de Software
.
Os métodos polimórficos utilizam os conceitos de overloading e overrinding.
Apresente a diferença entre os dois conceitos.
Questão 10
289
Padrões de Projetos de Software
.
Os métodos polimórficos utilizam os conceitos de overloading e overrinding.
Apresente a diferença entre os dois conceitos.
Overloading: Sobrecarga de Método. Reescrever o método com uma nova
assinatura (atributos de entrada)
Overriding: Sobrescrita de Método. Reescrever o método na classe filho
(especialista), mesmo que ele já tenha sido implementada na classe mãe
(generalista), com propósitos específicos para tal.
Questão 10 – Resposta
290
Padrões de Projetos de Software
.
Segundo Metsker, o padrão de projeto GoF _ é aplicado para 
substituir a geração de instâncias não-inicializadas de uma classe, fornecendo 
novos objetos a partir de uma classe-exemplo.
a) MEDIATOR.
b) SINGLETON.
c) PROTOTYPE.
d) BUILDER.
e) FACTORY METHOD.
Questão 11
291
Padrões de Projetos de Software
.
Segundo Metsker, o padrão de projeto GoF _ é aplicado para 
substituir a geração de instâncias não-inicializadas de uma classe, fornecendo 
novos objetos a partir de uma classe-exemplo.
a) MEDIATOR.
b) SINGLETON.
c) PROTOTYPE.
d) BUILDER.
e) FACTORY METHOD.
Questão 11 – Resposta
292
Padrões de Projetos de Software
.
Assinale a afirmativa correta sobre o padrão Builder:
a)Deve-se é separar no construtor da própria classe a lógica para criação de um objeto 
e concentrar a lógica de criação em uma hierarquia de herança.
b)é uma abordagem que não facilita a criação de objetos com diferentes configurações 
e representações, tornando o código dependente a complexidade das classes
relacionadas.
c)Um dos principais objetivos do padrão Builder é separar o algoritmo de criação de um 
objeto complexo tanto da especificação, quanto das partes que o compõem.
d)A legibilidade da solução final, ou seja, para entender como um objeto é criado e sob 
quais condições, fica comprometida.
e)Deve-se é embutir no construtor da própria classe a lógica para criação de um objeto 
ou ainda distribuir a lógica de criação em vários métodos adicionais.
Questão 12
293
Padrões de Projetos de Software
.
Assinale a afirmativa correta sobre o padrão Builder:
a)Deve-se é separar no construtor da própria classe a lógica para criação de um objeto 
e concentrar a lógica de criação em uma hierarquia de herança.
b)é uma abordagem que não facilita a criação de objetos com diferentes configurações 
e representações, tornando o código dependente a complexidade das classes
relacionadas.
c)Um dos principais objetivos do padrão Builder é separar o algoritmo de 
criação de um objeto complexo tanto da especificação, quanto das partes 
que o compõem.
d)A legibilidade da solução final, ou seja, para entender como um objeto é criado e sob 
quais condições, fica comprometida.
e)Deve-se é embutir no construtor da própria classe a lógica para criação de um objeto 
ou ainda distribuir a lógica de criação em vários métodos adicionais.
Questão 12
294
Padrões de Projetos de Software
.
• Em padrão de projeto existe uma situação onde uma classe chama um método 
abstrato especificado em alguma classe abstrata (ou interface) e a subclasse concreta 
vai decidir que tipo exato de objeto criar e retornar.
• Baseado nessa descrição marque a alternativa que aponta o padrão relacionado.
a) Singleton.
b) Builder.
c) Mediator.
d) Factory Method.
e) Facade.
Questão 13
295
Padrões de Projetos de Software
.
• Em padrão de projeto existe uma situação onde uma classe chama um método 
abstrato especificado em alguma classe abstrata (ou interface) e a subclasse concreta 
vai decidir que tipo exato de objeto criar e retornar.
• Baseado nessa descrição marque a alternativa que aponta o padrão relacionado.
a) Singleton.
b) Builder.
c) Mediator.
d)Factory Method.
e) Facade.
Questão 13
296
Padrões de Projetos de Software
.
Uma classe com alto acoplamento faz com que o reuso fique comprometido.
Apresente uma justificativa para esse problema.
Questão 14
297
Padrões de Projetos de Software
.
Uma classe com alto acoplamento faz com que o reuso fique comprometido.
Apresente uma justificativa para esse problema.
O problema ocorre pois para reaproveitar métodos acoplados torna-se 
necessária a presença adicional das classes relacionadas, dificultando o 
processo de reutilização.
Questão 14 – Resposta
298
• Ao término desta Unidade você deverá ser capaz de 
explanar sobre:
Motivações para