Padrões de Projeto de Software Aula 05

Prévia do material em texto

AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
PADRÕES DE ESTRUTURA 
STRUCTURAL PATTERNS 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Padrões Estruturais 
6. Adapter 
7. Bridge 
8. Composite 
9. Decorator 
10.Façade 
11.Flyweight 
12.Proxy 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
• Objetivo: 
• Converter a interface de uma classe em outra 
interface esperada pelos clientes. 
• Permitir a comunicação entre classes que não 
poderiam trabalhar juntas devido à 
incompatibilidade de suas interfaces. 
 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
Cliente 
operacao() 
ClasseExistente 
metodoUtil() 
void operacao() { 
 metodoEsperado(); 
} 
Adaptador 
metodoEsperado() 
void metodoEsperado() { 
 metodoUtil(); 
} 
Problema Solução 
Deseja 
utilizar 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
• Estrutura: 
 
<<interface>> 
Alvo 
operacao() 
Cliente 
Adaptador 
operacao() 
ClasseExistente 
metodoUtil() 
ClasseExistente ce; 
... 
ce.metodoUtil(); 
implementa 
• Cliente: aplicação que colabora com objetos que implementam Alvo 
• Alvo: define a interface requerida pelo Cliente 
• ClasseExistente: classe dos objetos que requerem adaptação 
• Adaptador: adapta a interface do Recurso à interface Alvo 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
• Estrutura (Usando herança múltipla): 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
• Estrutura (Usando composição): 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
6. Adapter 
Aplicabilidade 
– Use o Padrão Adapter quando: 
• Deseja-se usar uma classe existente, e sua interface não é 
compatível com uma que se necessita 
• Deseja-se criar uma classe reusável que coopera com 
classes não-relacionadas ou não previstas a priori, isto é, 
classes que não apresentam necessariamente interfaces 
compatíveis 
• (Somente para ObjectAdapter) precisa-se usar várias 
subclasses existentes (de Adaptee), mas é impraticável 
adaptar as interfaces de cada uma através de herança. 
• Um ObjectAdapter pode resolver isto adaptando 
abstratamente a interface da superclasse. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
7. Bridge 
Objetivo: 
• Desacoplar a abstração da sua implementação, de 
modo que as duas possam variar independentemente 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
7. Bridge 
Motivação 
• Quando uma abstração pode ter várias implementações 
a solução usual é acomodar todas as implementações 
através de herança 
• No entanto, herança liga de forma permanente uma 
abstração a uma implementação 
• O padrão Bridge permite colocar as abstrações e suas 
implementações em diferentes hierarquias de classes, e 
permite que variem de forma independente 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
7. Bridge 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
7. Bridge 
Aplicabilidade: 
• Use o Padrão Bridge Quando: 
 Você quer evitar ligação permanente entre uma 
abstração e sua implementação. Pode ser, por 
exemplo, quando se deseja variar a implementação 
em run-time 
 Tanto a abstração quanto a implementação devem 
ser extensíveis através de herança 
 Mudanças na implementação de uma abstração não 
devem ter impacto sobre o cliente 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
8. Composite 
• Objetivo: 
• Compor objetos em estruturas de árvore para 
representar hierarquias todo-parte. 
• Composite permite que clientes tratem objetos 
individuais e composições de objetos de maneira 
uniforme. 
 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
8. Composite 
Cliente 
Componente 
Individuo Grupo 
Todos são 
componentes 
• Cliente precisa tratar de 
maneira uniforme objetos 
individuais e composições 
desses objetos 
• Tratar grupos e indivíduos 
diferentes através de uma 
única interface 
 
Problema Solução 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
8. Composite 
Estrutura: 
 
 
:Composicao 
Cliente 
Componente 
operacao() 
Folha 
operacao() 
Composição 
operacao() 
add(Componente) 
remove(Componente) 
 
for (int i=0; i<filhos.length; i++) { 
 filho = filhos[i]; 
 filho.operacao(); 
} 
filhos 
1..* 
:Composicao :Folha 
:Folha :Folha :Folha 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
8. Composite 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
8. Composite 
Aplicabilidade 
• quando se quer hierarquias de objetos que se 
relacionam como parte/todo 
• quando se quer que “clientes” ignorem a 
diferença entre composição de objetos e 
objetos individuais 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
9. Decorator 
Objetivo 
• Anexa dinamicamente responsabilidades adicionais a 
um objeto. Provê uma alternativa flexível ao uso de 
herança como modo de estender funcionalidade 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
9. Decorator 
Motivação 
• Algumas vezes se quer adicionar responsabilidades a um 
objeto, mas não à sua classe. Acontece, por exemplo, 
com a criação de interfaces gráficas, quando se deseja 
acrescentar uma borda a um componente qualquer ou um 
scrollbar a uma área de texto. 
• Uma forma de se acrescentar responsabilidades é através 
de herança, mas isto torna o projeto inflexível, pois a 
escolha da borda é definida em tempo de compilação. 
Neste caso o cliente não pode controlar como, onde e 
quando decorar o componente com uma borda. 
• Uma abordagem mais flexível é inserir o componente em 
outro objeto que adiciona a borda, um Decorator. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
9. Decorator 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
9. Decorator 
Aplicabilidade: 
• Use o padrão Decorator: 
• Para adicionar responsabilidades a objetos individuais 
de forma dinâmica e transparente, sem afetar outros 
objetos 
• Para responsabilidades que podem ser removidas 
• Quando extensão através de herança é impraticável. 
Algumas vezes uma grande quantidade de extensões 
independentes são possíveis e seria necessário um 
imenso número de subclasses para suportar cada 
combinação possível entre elas. 
Consequências: 
• Mais flexibilidade que herança 
• Evita incorporação forçada de comportamentos desnecessários 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA- zavaleta.jorge@gmail.com 
10. Façade 
Objetivo: 
• Prover uma interface unificada para o conjunto de 
interfaces de um subsistema. Define uma interface de 
alto nível que faz um subsistema mais fácil de usar. 
Motivação: 
• Estruturar um sistema em subsistemas contribui para 
reduzir sua complexidade. A dependência entre 
subsistemas pode ser minimizada através do uso de 
um objeto Fachada, o qual provê uma interface única e 
uniforme para as diversas funcionalidades de um 
subsistema. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
10. Façade 
Estrutura: 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
10. Façade 
Aplicabilidade: 
• Use o Padrão Façade quando: 
• Você quer prover uma interface simplificada para um 
subsistema complexo. Um Façade pode prover uma 
visão simples do subsistema, suficiente para a 
maioria dos clientes 
• Existem muitas dependências entre clientes e 
classes da implementação. O Façade reduz esta 
dependência e promove independência e 
portabilidade 
• Você quer criar sistemas em camadas. Um Façade 
provê o ponto de entrada para cada camada (nível) 
do subsistema. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
10. Façade 
Consequências: 
• Promove acoplamento fraco entre o subsistema e seus 
clientes 
• No entanto, não evita que aplicações possam acessar 
diretamente as subclasses do sistema, se assim o 
desejarem. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
11. Flyweight 
Objetivo: 
• Usar compartilhamento para suportar eficientemente 
grandes quantidades de objetos de granularidade 
fina. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
/* Trabalho de PSS*/ 
public static ... 
System.out.println ... 
Objeto 
Linha 
Objeto 
Linha 
p 
u 
b 
l 
i 
c 
11. Flyweight 
Motivação: 
• Aplicações que utilizam grande número de objetos 
 Exemplo de Problema: desenvolver um editor de texto 
onde cada caracter é representado por um objeto. Pode 
não haver recursos (memória) sufientes para textos 
muito grandes. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
11. Flyweight 
Motivação: 
• Aplicações que utilizam grande número de objetos 
 Exemplo de solução: monta-se um pool de objetos 
compartilhados. Cada caracter tem um objeto. Com 100 
objetos (tabela ASCII) poderíamos montar textos de 
qualquer tamanho 
System.out.println (“Padrões de Projetos de Software”) 
a b c d e f g . . . 
Pool de Flyweight 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
11. Flyweight 
Estrutura: 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
11. Flyweight 
Aplicabilidade: 
• Aplicação utiliza grande número de objetos 
• Custos de armazenamento altos 
• A maior parte dos estados de objetos pode ser tornada 
extrínseca (estados externalizados) 
• Muitos objetos podem ser substituídos por poucos objetos 
compartilhados 
• Aplicação não depende da identidade dos objetos. obs: 
testes de identidade produzirão o valor verdadeiro para 
objetos conceitualmente distintos. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
• Objetivo: 
• Disponibilizar um substituto para outro objeto, 
controlando o acesso a ele. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
• Motivação: 
• Várias razões para controlar acesso a um objeto, 
como por exemplo: 
 deferir o custo de criação e inicialização para o 
momento de uso (objetos sob demanda); 
 Prover um representante local para um objeto 
remoto; 
 Proteger o objeto original. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
• Estrutura: 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
12. Proxy 
Aplicabilidade 
• O Padrão Proxy é usado sempre que se precisa de uma referência 
a um objeto, que seja mais versátil ou sofisticada do que um 
simples ponteiro. 
• As principais situações são: 
 Remote Proxy: provê um representante local para um objeto em 
um espaço de endereçamento diferente 
 Virtual Proxy: cria objeto sob demanda 
 Protection Proxy: controla acesso ao objeto original 
 Smart References: executa operações adicionais quando o 
objeto é acessado 
o Contagem de referências, carga de objetos persistentes, 
locks 
 Copy-on-write: compartilhar grandes objetos, fazendo uma 
cópia apenas se necessário