Padrões de Projeto de Software Aula 05.02

Prévia do material em texto

AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
PADRÕES DE COMPORTAMENTO 
BEHAVIORAL PATTERNS 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
Padrões Comportamentais 
13. Chain Of Responsibility 
14. Command 
15. Interpreter 
16. Iterator 
17. Mediator 
18. Memento 
19. Observer 
20. State 
21. Strategy 
22. Template Method 
23. Visitor 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
13. Chain of Responsibility 
Objetivo: 
• Evita acoplar o remetente de uma requisição ao seu 
destinatário ao dar a mais de um objeto a chance de 
servir a requisição. 
• Compõe os objetos em cascata e passa a requisição 
pela corrente até que um objeto a sirva. 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
13. Chain of Responsibility 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
13. Chain of Responsibility 
Estrutura: 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
14. Command 
Objetivo: 
• Encapsular uma requisição como um objeto, permitindo 
que clientes parametrizem diferentes requisições, filas ou 
requisições de log, e suportar operações reversíveis. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
14. Command 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
14. Command 
Aplicabilidade: 
• Deseja-se parametrizar objetos com uma ação a ser 
realizada: 
• O Command é o substituto orientado a objetos para 
os call-backs procedurais; 
• Para especificar, enfileirar e executar requisições em 
momentos diferentes: 
• O lifetime dos objetos Command é independente da 
requisição original; 
• Se o receptor puder ser representado de uma forma 
independente de espaço de endereçamento, o 
Command pode ser transferido para ser executado 
em um diferente processo ou host; 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
14. Command 
Aplicabilidade: 
• Deseja-se suporte a undo: 
• A operação execute() do Command pode armazenar 
estado necessário para reverter os efeitos do 
comando; 
• A interface do Command é estendida com uma 
operação unexecute(); 
• Commands já executados são armazenados em uma 
lista de histórico; 
• Undo e redo ilimitado através da navegação para trás 
e para frente no histórico, executando as operações 
unexecute() e execute(), respectivamente; 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
15. Interpreter 
Objetivo 
• Dada uma linguagem, definir uma representação para 
sua gramática junto com um interpretador que usa a 
representação para interpretar sentenças na linguagem. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
15. Interpreter 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
15. Interpreter 
Aplicabilidade 
• Quando a gramática for simples. Para gramáticas 
complexas uma melhor alternativa é utilizar os geradores 
automáticos de parsers; 
• Quando eficiência não for um problema crítico. Os 
interpretadores mais eficientes não utilizam árvores 
sintáticas diretamente e sim outras estruturas, tais como 
autômatos; 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
16. Iterator 
Objetivo: 
• Disponibilizar uma forma de acesso sequencial aos 
elementos de um agregado sem expor a sua 
representação subjacente. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
16. Iterator 
Estrutura: 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
16. Iterator 
Aplicabilidade: 
• Para acessar o conteúdo de um agregado sem expor a 
sua representação interna; 
• Para suportar múltiplas varreduras em objetos agregados; 
• Para disponibilizar uma interface uniforme para varredura 
de objetos agregados (iteração polimórfica); 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
17. Mediator 
Objetivo: 
• Define um objeto que encapsula o modo como um 
conjunto de objetos interage. 
• Promove um acoplamento fraco entre objetos, evitando 
que referenciem diretamente um ao outro e permitindo 
que se possa variar a interação entre eles de modo 
independente. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
17. Mediator 
Estrutura: 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
17. Mediator 
Estrutura: 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
17. Mediator 
Aplicabilidade: 
• Utilize o padrão Mediator quando: 
• Um conjunto de objetos se comunica de uma forma 
bem definida, porém complexa. As interdependências 
resultantes não são estruturadas e são de difícil 
compreensão; 
• O reuso de objetos é difícil uma vez que um objeto se 
refere e se comunica com muitos outros objetos; 
• Um comportamento que é distribuído entre várias 
classes deve ser customizado sem o uso excessivo 
de subclasses; 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
18. Memento 
Objetivo 
• Externalizar o estado interno de um objeto para que o 
objeto possa ter esse estado restaurado posteriormente, 
isto é, Capturar e externalizar o estado interno de um 
objeto sem quebrar o encapsulamento. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
18. Memento 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
18. Memento 
Aplicabilidade 
• Use o padrão Memento quando: 
• Quando um snapshot do (parte do) estado de um 
objeto precisa ser armazenado para que ele possa 
ser restaurado ao seu estado original 
posteriormente; 
• Quando uma interface direta para se obter esse 
estado iria expor detalhes de implementação e 
quebrar o encapsulamento do objeto; 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
19. Observer 
Objetivo 
• Definir uma dependência um-para-muitos entre objetos 
para que quando um objeto mudar de estado, todos os 
seus dependentes sejam notificados e atualizados 
automaticamente. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
19. Observer 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
19. Observer 
Aplicabilidade 
• Use o padrão observer em qualquer uma das seguintes 
situações: 
• Quando uma abstração tem dois aspectos, um 
dependente do outro; 
• Quando uma mudança num objeto exige mudanças 
em outros, e quando não se sabe quantos objetos 
necessitam ser mudados; 
• Quando um objeto deveria ser capaz de notificar 
outros objetos sem fazer hipóteses, ou usar 
informações, de quem são estes objetos. 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
20. State 
Objetivo: Permite que um objeto altere seu comportamento 
quando mudar seu estado, isto é, permitir que um objeto 
modifique o seu comportamento em função do seu estado 
interno. O objeto irá aparentar mudar de classe. 
AULA 5 
PADRÕESDE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
20. State 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
20. State 
Aplicabilidade: 
• O comportamento de um objeto depende do seu estado e 
ele tiver que mudar de comportamento em tempo de 
execução em função de uma mudança no seu estado; 
• As operações contiverem grandes estruturas condicionais, 
com muitas alternativas. Frequentemente, tais estruturas 
irão conter grandes porções de código que irão se repetir 
através de várias operações, gerando replicação 
desnecessária de código. O padrão State coloca cada 
ramo da estrutura condicional em uma classe separada, 
permitindo, assim, tratar os estados como se fossem 
objetos e tornar mais simples a implementação de uma 
máquina de estados; 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
21. Strategy 
Objetivo 
• Definir uma família de algoritmos, encapsular cada um, e 
fazê-los intercambiáveis. 
• O padrão Strategy permite que algoritmos mudem 
independentemente entre clientes que os utilizam. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
21. Strategy 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
21. Strategy 
Aplicabilidade 
• Muitas classes relacionadas diferem somente no seu 
comportamento. As estratégias fornecem uma maneira de 
configurar uma classe com um, dentre muitos 
comportamentos. 
• Você necessita de variantes de um algoritmo. Por 
exemplo, podemos definir algoritmos que reflitam 
diferentes soluções de compromisso entre espaço/tempo. 
• Um algoritmo usa dados que os clientes deveriam 
desconhecer. Use o padrão Strategy para evitar a 
exposição das estruturas de dados complexas, 
específicas do algoritmo. 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
22. Template Method 
Objetivo 
• Definir o esqueleto de um algoritmo dentro de uma 
operação, deixando alguns passos a serem preenchidos 
pelas subclasses. 
• O Template Method permite que suas subclasses 
redefinam certos passos de um algoritmo sem mudar sua 
estrutura. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
22. Template Method 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
22. Template Method 
Aplicabilidade 
• O padrão Template Method pode ser usado: 
• Implementar a parte invariante de um algoritmo uma 
única vez e deixar que as subclasses implementem o 
comportamento variante; 
• Quando o comportamento comum deve ser fatorado e 
localizado em uma classe comum para evitar 
duplicação de código; 
 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
23. Visitor 
Objetivo 
• Representar uma operação a ser realizada sobre os 
elementos de uma estrutura de objetos. 
• O Visitor permite definir uma nova operação sem mudar 
as classes dos elementos nos quais opera. 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
23. Visitor 
Estrutura 
AULA 5 
PADRÕES DE PROJETO DE SOFTWARE 
JORGE ZAVALETA - zavaleta.jorge@gmail.com 
23. Visitor 
Aplicabilidade 
• Uma estrutura de objetos contém muitas classes de 
objetos com interfaces que diferem e quando se deseja 
executar operações sobre estes objetos que dependem 
das suas classes concretas; 
• Muitas operações distintas e não relacionadas necessitam 
ser executadas sobre objetos de uma estrutura de objetos, 
e quando se deseja evitar “a poluição” das suas classes 
com estas operações; 
• As classes que definem a estrutura do objeto raramente 
mudam, porém, frequentemente se deseja definir novas 
operações sobre a estrutura.