Detalhamento dos Padrões - Estrutura

1

2

Detalhamento dos Padrões - Estrutura

Padrão Bridge Possui estrutura similar ao Padrão

Adapter, mas possui outra finalidade: separar a interface de sua implementação para que possam ser alteradas independentemente;

O Adapter serve para alterar a interface de um objeto já existente;

O Bridge tem a função de desacoplar uma abstração de sua implementação;

3


Padrão Bridge Problema

Quando uma abstração pode ter uma entre várias implementações possíveis, a maneira usual de utilizá-las é através da herança: Classe Abstrata define a interface para

abstração; Subclasses Concretas implementam a

classe abstrata de formas diferentes; Logo, teremos abordagem pouco flexível

em virtude da ligação da herança com a implementação;

4


Padrão Bridge Problema

5


Padrão BridgeSolução com Bridge

6


Padrão BridgeEstrutura

7


Padrão Bridge Participantes

Abstraction : Define a interface de abstração. Mantém uma referência a um objeto do tipo Implementor.

RefinedAbstraction : Estende a interface definida por Abstração.

Implementor : Define a interface para classes de implementação. Esta não tem a obrigação de corresponder exatamente à interface de abstração. De fato, as duas interfaces podem ser bastante diferentes. Tipicamente, a interface de implementação fornece apenas operações primitivas, cabendo à abstração a responsabilidade de definir operações de alto nível baseadas nestas primitivas.

ConcreteImplementatorA e ConcreteImplementatorB : Implementação concreta da interface definida por Implementor.

8


Padrão BridgeAplicabilidade Quando for necessário evitar uma ligação

permanente entre a interface e a implementação.

Quando alterações na implementação não puderem afetar clientes.

Quando implementações são compartilhadas entre objetos desconhecidos do cliente.

9


Padrão BridgeConseqüências Detalhes de implementação totalmente

inacessíveis aos clientes. Eliminação de dependências em tempo de

compilação das implementações. Implementação de abstração pode ser

configurada em tempo de execução.

10


Padrão BridgeCódigo Fonte – Exemplo...

11


Padrão DecoratorClassificação: Padrão de Objeto Anexar responsabilidades adicionais a

um objeto dinamicamente. Os Decorators oferecem uma

alternativa flexível ao uso de herança para estender uma funcionalidade;

12

Detalhamento dos Padrões

Padrão DecoratorProblema A primeira idéia é criar subclasses que

implementem as funcionalidades desejadasListaSincronizadaListaComEventosListaNaoModificavel

13


Padrão DecoratorProblema Mas e se desejarmos mais de uma

funcionalidade ao mesmo tempo? Nesse caso teremos uma explosão de

classes. As novas classes (além das 3 anteriores) poderiam ser chamadas: ListaNaoModificavelSincronizada ListaComEventosNaoModificavel ListaComEventosSincronizada ListaComEventosNaoModificavelSincronizada

14


Padrão DecoratorProblemaEssa solução tem alguns problemas:

Torna a hierarquia bastante complexa;

O número de classes cresce 2^n – 1, onde n são as funcionalidades;Isso significa que com apenas 5 funcionalidade, teríamos 31 classes de Lista.

15


Padrão Decorator Problema

Necessidade de adicionar responsabilidades aos objetos, com a impossibilidade de criar extensões das subclasses;

Às vezes é até possível realizar um grande número de extensões independentes, mas podem causar uma explosão de subclasses para suportar todas as combinações;

16


Padrão DecoratorObjetivo Adicionar responsabilidades a um objeto

Dinamicamente; Decoradores oferecem uma alternativa à

herança para estender funcionalidade

17


Padrão DecoratorMotivação

Algumas vezes queremos adicionar responsabilidades a objetos individuais e não a uma classe inteira;

As vezes as responsabilidades mudam ou aumentam com o tempo e isso requer uma solução flexível.

18


Padrão Decorator

19


Padrão Decorator Participantes

Componente: define a interface para objetos que podem ter responsabilidades acrescentadas a eles dinamicamente;

ConcreteComponente: define um objeto para o qual responsabilidades adicionais podem ser atribuídas;

Decorator: mantém uma referência para um objeto Componente e define uma interface que segue a interface Componente;

ConcreteDecoratorN: acrescenta responsabilidades ao componente;

20


Padrão Decorator

21


Padrão Decorator

22


Padrão DecoratorAplicabilidade

Utilizado para adicionar responsabilidades a objetos individuais de forma dinâmica e transparente, isto é, sem afetar outros objetos, da mesma forma, quando se quer retirar responsabilidades;

Quando a utilização de heranças para a implementação do mesmo afetará a flexibilidade do sistema;

23


Padrão DecoratorConseqüências

Fornece uma flexibilidade maior do que a herança estática.

Evita a necessidade de colocar classes sobrecarregadas de recursos em uma posição mais alta da hierarquia.

Simplifica a codificação permitindo que você desenvolva uma série de classes com funcionalidades específicas, em vez de codificar todo o comportamento no objeto.

Aprimora a extensibilidade do objeto, pois as alterações são feitas codificando novas classes.

24


Padrão Decorator Código Fonte – Exemplo ...

25

Detalhamento dos Padrões - Comportamentais

Padrão InterpreterClassificação: Padrão de Classe Dada uma linguagem, define uma

representação para sua gramática, juntamente com um interpretador que usa a representação para interpretar sentenças na linguagem;

A estrutura do padrão deve definir a gramática da linguagem e sua implementação deve permitir a interpretação das sentenças que respeitam a gramática definida;

26


Padrão Interpreter Pode ser utilizado para representar e

resolver problemas que possam ser expressos sob a forma de uma linguagem formal simples;

27


Padrão Interpreter Solução

Símbolos Terminais

Símbolo Não

Terminal

28


Padrão Interpreter ExpressãoAbstrata: fornece a interface comum a

todos os nós da árvore; Expressão Completa: implementa a operação de

interpretação para os símbolos terminais; Expressão Incompleta: implementa a operação de

interpretação para os símbolos não terminais; A operação de interpretação é chamada

recursivamente e a base da recursão é um símbolo terminal;

Contexto: contém informações globais ao interpretador, tal como o resultado das operações realizadas;

Cliente: constrói a árvore sintática abstrata a partir de instâncias de nós terminais e não-terminais;

29


Padrão Interpreter

Resultado

30


Padrão InterpreterAplicabilidade

Quando existir uma linguagem para interpretar;

Gramáticas simples. Em gramáticas complexas use um parser;

31


Padrão InterpreterConseqüências

Facilidade em modificar e estender a linguagem;

Gramáticas complexas são difíceis de manter;

Adiciona novas formas de interpretar as expressões;

32


Padrão Interpreter

33


Padrão Interpreter

34


Padrão Interpreter

35


Padrão Interpreter

36


Padrão Template MethodClassificação: Padrão de Classe Define o esqueleto de um algoritmo numa

operação, deixando que subclasses completem algumas das etapas;

Permite que subclasses redefinem determinadas etapas de um algoritmo sem alterar a estrutura do algoritmo;

Subclasses fazem override das operações para prover um comportamento concreto;

Este padrão é a base para a construção de frameworks.

37


Padrão Template MethodEstrutura

38


Padrão Template MethodParticipantes

ClasseAbstrata: Define operações abstratas que as subclasses concretas definem para implementar certas etapas do algoritmo; Implementa um Template Method definindo o esqueleto de um algoritmo: O Template Method chama várias operações, entre as

quais as operações abstratas da classe;

ClasseConcreta: Implementa as operações abstratas para desempenhar as etapas do algoritmo que tenham comportamento específico a esta subclasse

39


Padrão Template Method Aplicabilidade Quando a estrutura fixa de um algoritmo puder ser definida

pela superclasse deixando certas partes para serem preenchidos por implementações que podem variar;

Para implementar partes que não variam de um algoritmo uma única vez e deixar subclasses implementarem o comportamento variável;

Quando um comportamento comum entre as subclasses deveria ser decomposto e localizado numa classe comum para evitar duplicação É um passo freqüente de "refactoring" de código

Primeiro identifique as diferenças; Coloque as diferenças em novos métodos; Substitua o código das diferenças por uma chamada a um dos

novos métodos;

40


Padrão Template MethodConseqüências Template Methods constituem uma das

técnicas básicas de reuso de código; São particularmente importantes em

frameworks e bibliotecas de classes para o fatoramento de comportamento comum;

Deve explicitamente dizer quais os métodos que DEVEM ser sobrescritos e os que PODEM ser sobrescritos;

41


Padrão Template MethodExemplo – Código Fonte JAVA...

42


Padrão Chain of ResponsabilityClassificação: Padrão de Objeto Permite que uma requisição passe por

uma corrente de objetos até encontrar um que a processe;

Evita acoplar o remetente de um 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;

43


Padrão Chain of ResponsabilityMotivação: Uma máquina de refrigerantes necessita

armazenar em locais diferentes cada tipo de moeda possível.

Pode ser útil que um objeto receba a moeda, mas se ele não for capaz de armazenar no local correto, passe-o para outro objeto buscando a colocação correta da moeda.

Isso é um exemplo de tentativa de desacoplamento, já que se alguém não pode resolver determinada tarefa ocorre uma delegação da responsabilidade para outro objeto de forma totalmente transparente.

44


Padrão Chain of Responsability

• Permitir que vários objetos possam servir a uma requisição ou repassá-la;• Permitir divisão de responsabilidade de forma transparente;

[Argonavis]

45



[Argonavis]

46


Padrão Chain of ResponsabilityProcessador: define a interface

para as solicitações; implementa a referência ao sucessor;

ProcessadorConcreto: trata as solicitações pelas quais ele é responsável; pode acessar seu sucessor, caso não consiga processar a informação;

Cliente: inicia a solicitação para um objeto do tipo ProcessadorConcreto;

[Argonavis]

47


48



[Argonavis]

49


Padrão Chain of ResponsabilityExemplo:

Mecanismo de Exceção em Java;Quando ocorre um erro em uma classe

a máquina virtual verifica se a classe possui o tratamento de exceção;Caso não possua, a classe pode indicar que a exceção pode ser tratada pela classe que a chamou;

A cadeia é construída em tempo de execução;

[Argonavis]

50



Aplicabilidade: Mais de um objeto pode tratar de um pedido, e o

tratador de pedidos (processador) não é conhecido a priori. O processador deve ser buscado automaticamente de forma ascendente;

Você quer emitir um pedido para um de vários objetos sem especificar o recebedor de forma explícita;

O conjunto de objetos que pode tratar de um pedido deve ser configurado dinamicamente.

51


Padrão Chain of ResponsabilityConseqüências: Acoplamento reduzido:

Evita que um objeto (client) seja forçado a tomar conhecimento do outro (processador);

O objeto só precisa saber que o pedido foi tratado apropriadamente;

A estrutura da cadeia não precisa ser conhecida; Flexibilidade na atribuição de responsabilidades

para objetos (subclasses, alteração dinâmica da cadeia);

Sucesso no tratamento do pedido não é garantido.

52



Código Fonte – Exemplo ...

[Argonavis]

53


Padrão CommandClassificação: Padrão de ObjetoEncapsular uma requisição como

um objeto, permitindo que clientes parametrizem diferentes requisições;

[Argonavis]

54


Padrão CommandUma aplicação complexa pode

exigir a realização de diversos comandos diferentes;

Algumas vezes é necessário a seleção de objetos sem saber nada sobre a operação que está sendo executada;

[Argonavis]

55


Padrão CommandMotivação: Algumas vezes é necessário se fazer uma

solicitação de serviço sem conhecimento algum do tipo de operação que está sendo requerida.

Na construção de um menu, por exemplo. O padrão Command permite que um menu

possa solicitar execução de pedidos sem conhecer a natureza destes pedidos,pois o próprio objeto encapsula os detalhes da execução do pedido.

56


Padrão Command

[Argonavis]

57

Detalhamento dos Padrões - ComportamentaisPadrão Command

Comando: define a interface para execução de uma operação;

ComandoConcreto: define um vínculo entre o objeto Receptor e a ação; implementa o executar() a partir das invocações das correspondentes operações do receptor;

Cliente: cria um objeto do tipo ComandoConcreto;

Executor: solicita ao Comando a execução da solicitação;

Receptor: sabe como executar as operações associadas a uma solicitação; qualquer classe pode funcionar como receptor;

58


Padrão CommandaReceptor aCliente aComandoConcreto aComando Executor

59


Padrão Command

60


Padrão CommandAplicabilidade Parametrizar objetos com uma ação a executar. Especificar, armazenar e executar pedidos em

momentos diferentes: Commands podem ser transferidos entre espaços de

endereçamento e máquinas. Suportar undo: a operação execute pode armazenar o

estado para reverter os efeitos do próprio comando. Suportar ‘logs’ de modificações: através da inclusão de

undoable Commands em meio persistente. Estruturar um sistema em torno de operações de alto

nível: constituídas internamente por várias operações primitivas. Facilidades para extensão do sistema.

61


Padrão CommandConseqüências Command desacopla o objeto que invoca a

operação daquele que sabe como executá-la. Commands são objetos de primeira classe,

ou seja, podem ser manipulados e estendidos como qualquer outro objeto.

É fácil acrescentar novos Commands porque não é preciso mudar classes existentes.

62


Padrão CommandExemplo – Código Java ...

63


Padrão IteratorClassificação: Padrão de ObjetoFornece um meio de acessar,

sequencialmente, os elementos, sem expor sua representação interna;

64


Padrão IteratorMotivação: Objetos agregados como listas, tabelas hash,

dicionários, por exemplo, devem permitir que se acessem seus elementos de modo abstrato, sem que a representação interna de sua estrutura seja exposta;

Eventualmente também pode se desejar fazer duas travessias concorrentes sobre um mesmo objeto agregado.

O padrão Iterator permite a criação de tais facilidades.

65


Padrão Iterator

[Argonavis]

66


Padrão IteratorEstrutura

67

Detalhamento dos Padrões - Comportamentais Padrão Iterator Iterator:define a interface para acessar

e percorrer os elementos; ConcreteIterator (ListIterator,

SkipListIterator): implementa interface Iterator; mantém o controle na posição corrente no percurso do agregado;

Aggregate (AbstractList): define uma interface para o objeto iterator;

ConcreteAgregate (List, SkipList): implementa a interface de criação do iterador para retornar uma instância do ConcreteIterator;

68


Padrão IteratorAplicabilidade

Se desejar acessar o conteúdo de um objeto agregado sem expor sua representação interna;

Se desejar suportar múltiplas formas de percorrer um objeto agregado;

Se quiser prover uma interface uniforme para percorrer diferentes estruturas agregadas. Suportar iteração polimórfica.

69


Padrão IteratorConseqüências

Suporte a variações na maneira de se atravessar um objeto agregado (pre-order, pós-ordem, em-ordem);

Simplificação da interface do agregado;

Mais de um cursor pendente sobre um agregado.

70


Padrão IteratorExemplo

71


Padrão IteratorCódigo Fonte – Exemplo....

Cast de todos os Objetos Retornados

72


Padrão IteratorCódigo Fonte – Exemplo...

73


Padrão MediatorClassificação: Padrão de ObjetoPermite encapsular a forma como

os objetos interagem;

74


Padrão MediatorProblema: Distribuição de comportamentos entre

diversas classes, com a intenção de melhorar a reusabilidade desses pequenos trechos de código.

Com muitas classes, a complexidade dos relacionamentos aumenta, ou seja, o acoplamento entre objetos fica forte.

Se houver necessidade de alteração de um comportamento, é necessário alterar várias classes.

75


Padrão MediatorProblema:

Como permitir que um grupo de objetos se comunique entre si sem que haja acoplamento entre eles?

Como remover o forte acoplamento presente em relacionamentos muitos para muitos?

Como permitir que novos participantes sejam ligados ao grupo facilmente?

76

Detalhamento dos Padrões - ComportamentaisPadrão MediatorSolução: Um objeto Mediador deve encapsular toda a

comunicação entre um grupo de objetos: Cada objeto participante conhece o mediador, mas

ignora a existência dos outros objetos; O mediador conhece cada um dos objetos

participantes: A interface do Mediador é usada pelos

colaboradores para iniciar a comunicação e receber notificações: O mediador recebe requisições dos remetentes; O mediador repassa as requisições aos destinatários; Toda a política de comunicação é determinada pelo

mediador (geralmente através de uma implementação concreta do mediador).

[Argonavis]

77


Padrão MediatorSolução:

Introduzir um Mediator; Os objetos podem se comunicar sem se

conhecer; O Mediator centraliza o comportamento;

[Argonavis]

78


Padrão MediatorEstrutura:

[Argonavis]

79


Padrão Mediator Mediator: define uma interface para a

comunicação com os objetos Colleague; ConcreteMediator:implementa

comportamento cooperativo pela coordenação de objetos Colleague;conhece e mantém seus colleagues;

Colleague: cada casse Colleague conhece seu objeto Mediator; Cada Colleague se comunica com seu mediador sempre que o mesmo se apresentar em uma situação na qual seria necessário se comunicar com outro Colleague;

80


Padrão MediatorAplicabilidade:

O reuso for difícil, uma vez que o objeto se comunica ou referencia muitos outros; O mediator simplifica o relacionamento entre os objetos;

Quando o comportamento distribuído entre diversas classes deve ser personalizado sem excesso de subclasses.

81


Padrão MediatorConseqüências: Limita hierarquia de subclasses apenas à

classe Mediator; Promove desacoplamento entre Colleagues; Simplifica protocolos entre objetos: muitos-

para-muitos substituido com um-para-muitos;

Abstrai como os objetos cooperam (ajuda a entender o funcionamento dos objetos);

Centraliza comportamento.

82


Padrão Mediator Código Fonte – Exemplo ...

83


Exercícios

84


Padrão Memento Classificação: Padrão de Objeto Sem violar o encapsulamento, capturar e

deixar disponível o estado interno de um objeto para que o objeto possa ter esse estado restaurado posteriormente;

85


Padrão Memento Problema:

É preciso guardar informações sobre um objeto suficientes para desfazer uma operação, mas essas informações não devem ser públicas;

[Argonavis]

86


Padrão Memento Solução:

Um memento é um pequeno repositório para guardar estado dos objetos Pode-se usar outro objeto, um string, um arquivo

Memento guarda um snapshot no estado interno de outro objeto - a Fonte Um mecanismo de Undo irá requisitar um

memento da fonte quando ele necessitar verificar o estado desse objeto;

A fonte reinicializa o memento com informações que caracterizam seu estado atual;

Só a fonte tem permissão para recuperar informações do memento;

87


Padrão Memento Estrutura:

Guarda os mementos da Fonte

88


Padrão Memento

Estrutura (Exemplo):

Fonte

Zelador

89


Padrão Memento Dinâmica:

90


Padrão Memento

91


Padrão Memento

92

Detalhamento dos Padrões - Comportamentais Padrão Memento Exemplo:

Implementar Memento em Java pode ser realizado aplicando o encapsulamento de pacotes;

Pacotes pequenos contendo apenas as classes que precisam compartilhar estado;

93


Padrão Memento Aplicabilidade:Um snapshot do (parte do) estado

de um objeto precisa ser armazenada para que ele possa ser restaurado ao seu estado original posteriormente;

Uma interface direta para se obter esse estado iria expor detalhes de implementação e quebrar o encapsulamento do objeto;

94


Padrão Memento Conseqüências:

Vantagens: O estado do Fonte é guardado fora dele sem a

perda do encapsulamento. O Fonte é simplificado por não ter a

responsabilidade de gerenciamento de estados anteriores.

Desvantagens: O uso de mementos pode ser uma solução cara

(muita memória), dependendo do tamanho e do número de estados a serem salvos.

O Zelador ganha a responsabilidade de deleção dos mementos armazenados.

95


Padrão Observer Classificação: Padrão de Objeto Define uma dependência 1-para-n entres

objetos, de modo que quando o estado de um objeto é alterado todos seus dependentes são notificados e atualizados automaticamente.

96


Padrão Observer Motivação: Suponha que você deseja fornecer várias visões

distintas de um mesmo objeto que funciona como um repositório de dados;

Cada visão é criada por um objeto observador independente;

Caso cada observador seja diretamente conectado ao repositório, isto criará uma dependência do repositório com relação aos diferentes observadores, o que lhe reduzirá a reusabilidade e flexibilidade;

O padrão Observer descreve uma forma de manutenção destes relacionamentos de modo que observadores e repositórios sejam facilmente substituídos;

97


Padrão Observer

98


Padrão ObserverEstrutura:

Solicita o cadastro

Cadastra e Remove os Observadores

99

Detalhamento dos Padrões - Comportamentais Padrão Observer Participantes: Sujeito

Conhece seu Observador. Qualquer número de objetos Observadores podem observar um Sujeito; Provê uma interface para acoplar e desacoplar objetos Observadores;

SujeitoConcreto Guarda o estado de interesse para ObservadorConcreto (isto

é observers); Envia uma notificação para seu(s) Observadores(s) quando

seu estado muda; Observador

Define uma interface de atualização para objetos que devem ser notificados sobre mudanças em um Sujeito;

ObservadorConcreto Mantém uma referência para um objeto SujeitoConcreto;

Guarda o estado que deve ficar consistente com o de Sujeito; Implementa o Observador atualizando a interface para manter seu estado consistente com o de Sujeito;

100


101


Padrão ObserverAplicabilidade: Quando uma abstração apresenta dois aspectos,

um dependente do outro. Encapsulando estes aspectos em objetos separados permite que você os varie e reutilize de forma independente;

Quando uma modificação em um objeto requer modificação em outros, e você não sabe (em tempo de programação) quantos objetos precisam ser modificados;

Quando um objeto deve ser apto a notificar outros objetos sem saber quem são estes objetos. Em outras palavras, quando você os quer fracamente acoplados;

102


Padrão ObserverConseqüências:Variação independente de observáveis e

observadores;É fácil adicionar observadores sem

modificar o observável ou os outros observadores;

Suporte a comunicação broadcast;Atualizações inesperadas (caso o

processo de notificação seja simplificado);

103


Padrão ObserverExemplo – Código Java...:

104


Padrão State Classificação: Padrão de Objeto Permitir a um objeto alterar o seu

comportamento quanto o seu estado interno mudar;

O objeto irá aparentar mudar de classe;

105


Padrão State Motivação: Usar objetos para

representar estados e polimorfismo para tornar transparente a execução de tarefas dependentes de estado.

106


Padrão State Estrutura:

107


Padrão State Participantes:

ContextDefine a interface de interesse para os Clientes;

StateDefine uma interface para encapsulamentos de estados associados ao estado de Context;

ConcreteStateImplementa um comportamento associado com um estado de context;

108


Padrão State Problema: Projetar um

computador de bordo. Um objeto, mostrador, com vários

comportamentos: Termômetro, Marcador de distância, Alarme de

Combustível Baixo, Indicador de velocidade média, Indicador de Consumo Médio.

O comportamento do mostrador depende de seu estado determinado por: Acionamento das chaves do painel Andamento do carro (combustível)

109


Padrão State Porque usar State:

Objeto (mostrador) tem estados e comportamentos;

Mostrador muda seu estado com base em eventos.

Os estados são claramente identificáveis O comportamento do objeto Mostrador é

dependente de seu estado; Estensibilidade é importante; Facilita separar a determinação do estado do

Mostrador do correspondente comportamento.

110


Padrão State Programa:

111

Padrão State


112


Padrão State Aplicabilidade:O Comportamento do objeto

depende do seu estado e precisa ser alterado em tempo de execução em função desse estado;

Operações que tenham muito código condicional que dependa do estado do objeto;

113


Padrão StateConseqüências:

Localização de comportamento específico em um objeto associado a um estado. Facilidade de extensão horizontal;

Transições de estado realizadas de forma explícita.

114


Padrão StateCódigo Fonte – Java...:

115


Padrão Strategy Classificação: Padrão de ObjetoDefine uma família de algoritmos,

encapsular cada um, e fazê-los intercambiáveis;

Strategy permite que algoritmos variem independentemente entre clientes que os utilizam;

116


Padrão Strategy Motivação:

Operações que são comuns a uma série de objetos de classes diferentes, com pequenas variações de comportamento.

Codificar tais métodos nas próprias classes, se tornariam mais complexas e difíceis de manter, além do inconveniente de termos que repetir o mesmo código várias vezes;

A classe no padrão Strategy torna-se uma espécie de agente capaz de selecionar o algoritmo para cada uso solicitados pelas classes clientes.

117


Padrão Strategy

Problema:

[Argonavis]

118


Padrão StrategyEstrutura:

119


Padrão StrategyParticipantes: Strategy (Compositor)

Define uma interface comum para todos os algoritmos suportados. Context usa esta interface para chamar o algoritmo definido por uma ConcreteStrategy;

ConcreteStrategy (SimpleCompositor, TeXCompositor) Implementa o algoritmo usando a interface de Strategy;

Context (Composition) É configurado com um objeto ConcreteStrategy; Mantém uma referência para um objeto Strategy; Pode definir uma interface que permite a Strategy

acessar seus dados;

120


Padrão StrategyAplicabilidade: Quando uma classe define muitos

comportamentos; Quando classes relacionadas forem

diferentes apenas no seu comportamento;

Quando você precisar de diferentes variações de um mesmo algoritmo.

121


Padrão StrategyConseqüências:

Hierarquias de classes Strategy podem facilitar a criação de comportamentos variados das famílias de algoritmos relacionados.

Strategy é uma alternativa ao uso de subclasses; A classe cliente pode escolher entre as diversas

implementações de comportamento em execução;

Desvantagem: a interface Strategy é compartilhada por todas as ConcreteStrategy fazendo com que implementações simples precisam declarar e receber parâmetros que não precisem.

122


Padrão StrategyCódigo Fonte – Java...:

123


Padrão Visitor Classificação:Padrão de Objeto Permite a definição de uma nova operação

sem alterar as classes dos elementos nos quais a operação atua;

As classes que definem a estrutura de objetos raramente mudam, mas a adição de novas operações é freqüente: Se as operações fossem colocadas na classes da

estrutura, a mudança seria mais complexa; Visitor permite agrupar operações relacionadas

numa mesma classe;

124


Padrão Visitor Problema:

125


Padrão Visitor Quando Usar: Uma estrutura de objetos contém muitas classes de

objetos com interfaces diferentes e você deseja realizar operações nestes objetos que dependem das classes concretas;

Muitas operações distintas e não relacionadas devem ser realizadas numa estrutura de objetos e você quer evitar "poluir" as classes com estas operações;

Visitor permite que você agrupe as operações relacionadas numa mesma classe;

As classes que definem a estrutura de objetos raramente muda mas a adição de novas operações é freqüente;

Se as operações fossem colocadas na classes da estrutura, a mudança seria mais complexa;

126


Padrão Visitor Visitor Permite:

Plugar nova funcionalidade em objetos sem precisar mexer na estrutura de herança;

Agrupar e manter operações relacionadas em uma classe e aplicá-las, quando conveniente, a outras classes (evitar espalhamento e fragmentação de interesses);

127


[Argonavis]

128


129

Detalhamento dos Padrões - ComportamentaisPadrão Visitor Visitante: Declara uma operação de visita

para cada classe de ElementoConcreto na estrutura de objetos.

VisitanteConcreto: Implementa cada operação declarada pelo Visitante. O VisitanteConcreto pode acumular estado

durante a varredura da estrutura de objetos. Elemento: Define uma operação accept()

que recebe um Visitante; ElementoConcreto: Implementa uma

operação accept() que recebe um Visitante e chama a operação de visita apropriada deste Visitante;

EstruturaDeObjetos: coleção de objetos;

130


Padrão Visitor

131


Padrão Visitor

ExemploAntes

132

133


Padrão Visitor

Exemplo Depois

134

135


Padrão Visitor Aplicabilidade Uma estrutura de objetos contém muitas

classes de objetos com interfaces diferentes e você quer fazer operações nestes objetos que dependem das classes concretas;

Muitas operações distintas e não relacionadas devem ser aplicadas a uma estrutura de objetos e você não quer "poluir" as classes dos objetos com tais operações; um visitante permite que você agrupe as

operações relacionadas e as mantenha numa única classe.

136


Padrão Visitor Conseqüências Visitor permite adicionar operações com

facilidade basta adicionar um novo visitante um visitante junta operações relacionadas e separa operações não relacionadas;

Evita espalhar operações relacionadas adicionar novos elementos concretos é difícil cada elemento concreto novo significa uma nova operação abstrata no visitante portanto, use o visitante se as operações mudarem com muito mais frequência do que a estrutura de objetos.

137


Exemplo – Código Java

138

Padrões de Projeto - Revisão

Padrões de Criação Padrões que têm a ver com a instanciação de objetos

Abstract Factory - Provê uma interface para criar famílias de objetos relacionados ou interdependentes sem especificar suas classes concretas.

Builder - Separa a construção de um objeto complexo da sua representação de forma que o mesmo processo de construção possa criar representações diferentes.

Factory Method - Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. O padrão Factory Method deixa uma classe repassar a responsabilidade de instanciação para subclasses.

Prototype - Especifica os tipos de objetos a criar usando uma instância-protótipo e cria novos objetos copiando este protótipo.

Singleton - Garante que uma classe tenha uma única instância e provê um ponto global de acesso à instância.

139

Padrões de Projeto - Revisão Padrões Estruturais Padrões que têm a ver com a composição de classes ou objetos

Adapter - Converte a interface de uma classe em outra interface com a qual os clientes estão prontos para lidar. O padrão Adapter permite que classes trabalhem conjuntamente apesar de interfaces incompatíveis.

Bridge - Desacopla uma abstração de sua implementação de forma que as duas possam mudar independentemente uma da outra.

Composite - Compõe objetos em estruturas de árvore para representar hierarquias Parte-Todo. O padrão Composite permite que clientes tratem objetos individuais e composições de objetos de uniformemente.

Decorator - Adiciona responsabilidades a um objeto dinamicamente. Decoradores provêem uma alternativa flexível à herança para estender funcionalidade.

Façade – Provê uma interface unificada para um conjunto de interfaces num subsistema. O padrão Façade define uma interface de mais alto nível, deixando o subsistema mais fácil de usar.

Flyweight - Usa o compartilhamento para dar suporte eficiente ao uso de um grande número de objetos de granularidade pequena.

Proxy - Provê um objeto procurador para um outro objeto para controlar o acesso a ele.

140

Padrões de Projeto - Revisão

Padrões de Comportamento Padrões que caracterizam formas de interação entre classes e

objetos Chain of Responsibility - Evita acoplar o enviador de um pedido ao

receptor dando oportunidade a vários objetos para tratarem do pedido. Os objetos receptores são encadeados e o pedido é passado na cadeia até que um objeto o trate.

Command - Encapsula um pedido num objeto, permitindo assim parametrizar clientes com pedidos diferentes, enfileirar pedidos, fazer log de pedidos, e dar suporte a operações de undo.

Interpreter - Dada uma linguagem, define uma representação de sua gramática e um interpretador que usa a representação da gramática para interpretar sentenças da linguagem.

Iterator - Provê uma forma de acessar os elementos de uma coleção de objetos seqüencialmente sem expor sua representação subjacente.

Mediator - Define um objeto que encapsule a forma com a qual um conjunto de objetos interagem. O padrão Mediator promove o acoplamento fraco evitando que objetos referenciem uns aos outros explicitamente e permite que suas interações variem independentemente.

141

Padrões de Projeto - Revisão Padrões de Comportamento Padrões que caracterizam formas de interação entre classes e

objetos Memento - Sem violar o princípio de encapsulamento, captura e

externaliza o estado interno de um objeto de forma a poder restaurar o objeto a este estado mais tarde.

Observer - Define uma dependência um-para-muitos entre objetos de forma a avisar e atualizar vários objetos quando o estado de um objeto muda.

State – Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto estará aparentemente mudando de classe com a mudança de estado.

Strategy - Define uma família de algoritmos, encapsula cada um, e deixe-os intercambiáveis. O padrão Strategy permite que o algoritmo varie independentemente dos clientes que o usam.

Template Method - Define o esqueleto de um algoritmo numa operação, deixando que subclasses completem algumas das etapas. O padrão Template Method permite que subclasses redefinem determinadas etapas de um algoritmo sem alterar a estrutura do algoritmo.

Visitor - Represente uma operação a ser realizada nos elementos de uma estrutura de objetos. O padrão Visitor permite que se defina uma nova operação sem alterar as classes dos elementos nos quais a operação age.

Detalhamento dos Padrões - Estrutura

Documents