Especialização em web com interfaces ricas

Especialização em web com interfaces

ricas

Padrões de Projeto - Comportamentais

Prof. Fabrízzio Alphonsus A. M. N. Soares

fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática

Universidade Federal de Goiás

Aula 9 25 de maio de 2012

Padrões de Projeto - Comportamentais I

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.

Padrões de Projeto - Comportamentais II

Estes padrões caracterizam um complexo fluxo de controle que é difícil de seguir em tempo de execução. Eles transportam sua atenção para longe do fluxo de controle e lhe permite concentrar-se apenas no modo como os objetos estão interconectados.

Padrões de Projeto - Comportamentais III

Lista de padrões comportamentais Chain of responsability Mediator Strategy Command Memento Template Method Interpreter Observer Visitor

Chain of responsability I

O padrão de projeto de software Chain of Responsibility repre-senta um encadeamento de objetos receptores para o processa-mento de uma série de solicitações diferentes.

Esses objetos receptores passam a solicitação ao longo da cadeia até que um ou vários objetos a tratem.

Chain of responsability II

Cada objeto receptor possui uma lógica descrevendo os tipos de solicitação que é capaz de processar e como passar adiante aquelas que requeiram processamento por outros receptores. A delegação das solicitações pode formar uma árvore de re-cursão, com um mecanismo especial para inserção de novos receptores no final da cadeia existente.

Chain of responsability III

Dessa forma, fornece um acoplamento mais fraco por evitar a associação explícita do remetente de uma solicitação ao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicitação.

Chain of responsability IV

Um exemplo da aplicação desse padrão é o mecanismo de he-rança nas linguagens orientadas a objeto: um método chamado em um objeto é buscado na classe que implementa o objeto e, se não encontrado, na superclasse dessa classe, de maneira recursiva.

Propósito I

Não conhecer de antemão qual objeto irá responder a uma determinada requisição.

Compor os objetos em cascata e passar a requisição pela corrente até que um objeto a sirva.

Evitar a união entre o remetente de uma solicitação e seu receptor, dando aos diversos objetos uma chance de tratar da solicitação

Motivação I

Em projetos orientados a objetos manter os objetos com acopla-mento fraco, mantendo específica e mínima a responsabilidade entre eles, faz com que mudanças sejam inseridas com menos risco de falhas. Os clientes apenas enxergam a interface visível do objeto permanecerem isolados de detalhes de implementação

Motivação II

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.

Motivação III

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

Aplicabilidade I

Mais de um objeto pode tratar de uma solicitação e este é desconhecido.

Uma solicitação deve ser emitida para um entre os vários objetos e o receptor, não sendo especificado

explicitamente.

O conjunto de objetos capaz de tratar da solicitação deve ser especificado dinamicamente.

Estrutura I

Participantes

Alimentador define a interface para tratar as solicitações e implementa a referência ao sucessor (opcional).

AlimentadorConcretoA, ..., AlimentadorConcretoN trata as solicitações pelas quais é responsável. Pode acessar seu sucessor. Se o AlimentadorConcreto pode tratar a solicitação, ele assim o faz; caso contrário ele repassa a solicitação para o seu sucessor.

Estrutura II

Requisição As instâncias de Requisição é que iram

transportar as informações para os alimentadores executarem algo.

Vantagens I

Evita acoplamento do transmissor de um requisição com seus receptores, fazendo com que mais de um projeto tenha a chance de manipular a requisição.

Encadeia os objetos receptores e passa a requisição ao longo dessa cadeia até que um objeto possa manipulá-lo. Reduz a vinculação.

Adiciona flexibilidade.

Permite que um conjunto de classes atue como uma classe; eventos produzidos em uma classe podem ser enviados para outras classes dentro da composição.

Padrão Command I

Encapsular uma solicitação como um objeto, desta forma per-mitindo que clientes parametrizem diferentes solicitações, en-fileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas.

Padrão Command II

Encapsular uma solicitação como um objeto, permitindo desta forma parametrizar clientes com diferentes solicitações, enfilei-rar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas.

Padrão Command III

Problema I

Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada ou sobre o receptor da mesma.

Motivação I

Algumas vezes é necessário emitir solicitações para objetos que nada sabem sobre a operação que está sendo solicitada ou sobre o receptor da mesma.

Motivação II

Exemplo: toolkits para construção de interfaces de usuário in-cluem objetos como botões de menus que executam uma soli-citação em resposta à entrada do usuário. Mas, o toolkit não pode implementar a solicitação explicitamente no botão ou no menu porque somente as aplicações que utilizam o toolkit sa-bem o que deveria ser feito e em qual objeto. Como projetistas de toolkits, não temos meios de saber qual é o receptor da solicitação ou as operações que ele executará.

Motivação III

O padrão Command permite a objetos de toolkit fazer solici-tações de objetos-aplicação não especificados, transformando a própria solicitação em um objeto. Este objeto pode ser arma-zenado e passado como outros objetos. A interface Command: Define uma interface para execução de operações. Na sua forma mais simples, inclui uma única operação execute().

Utilizar quando? I

Utilizar quando:

Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem procedural atra-vés de uma função callback, ou seja, uma função que é re-gistrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks;

Utilizar quando? II

Especificar, enfileirar e executar solicitações em tempos diferen-tes. Um objeto Command pode ter um tempo de vida indepen-dente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Com-mand para a solicitação para um processo diferente e lá atender a solicitação;

Utilizar quando? III

Suportar desfazer operações. A operação Execute, de Com-mand, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Command deve ter acrescen-tada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de des-fazer e redes-fazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente.

Aplicação I

A chave deste padrão é uma classe abstrata Command, a qual

declara uma interface para execução de operações. Na sua

forma mais simples, esta interface inclui uma operação abstrata Execute.

Aplicação II

As subclasses concretas de Command especificam um par receptor-ação através do armazenamento do receptor como uma variável de instância e pela implementação de Execute para invocar a so-licitação. O receptor tem o conhecimento necessário para poder executar a solicitação.

Estrutura I

Participantes:

Command Declara uma interface para a execução de uma operação.

ConcreteCommand Define uma vinculação entre um objeto Receiver e uma ação.

Implementa execute() através da invocação da(s) correspondente(s) operação(ções) no Receiver.

Client Cria um objeto ConcreteCommand e estabelece o seu receptor (Receiver).

Invoker Solicita ao Command a execução da solicitação.

Receiver Sabe como executar as operações associadas a uma solicitação.

Estrutura II

Qualquer classe pode funcionar como um Receiver.

Consequencias I

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. Um comando pode ser composto por outros comandos. Um exemplo disso é a classe MacroCommand descrita anteriormente. Em geral, comandos compostos são uma instância do padrão Composite.

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

Padrão interpreter I

Interpreter é um padrão de projeto de software que especifica como entender frases em uma determinada linguagem de pro-gramação.

O padrão de projeto Interpreter pode ser utilizado para represen-tar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples.

Padrão interpreter II

É usado para ajudar uma aplicação a entender uma declaração de linguagem natural e executar a funcionalidade da declaração.

Propósito I

Dada uma linguagem, cria uma representação para a gramática da linguagem, juntamente com um interpretador que usa esta representação para interpretar sentenças na linguagem.

Motivação I

O padrão Interpreter pode ser utilizado para representar e resol-ver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples.

O padrão Interpreter usa classes para representar cada regra de uma gramática (expressão regular).

Consequencias I

Vantagem: Flexibilidade

Padrão iterator I

Fornecer uma maneira de acessar seqüencialmente os elementos de um objeto agregado sem expor sua implementação

Motivação I

Padrão Iterator retira a responsabilidade de acesso e percurso do objeto, listando e colocando em um objeto iterator.

Aplicabilidade I

O acesso a um objeto da coleção é requerido sem precisar expor sua representação interna.

Diversas travessias de objetos devem ser suportadas na coleção.

Uma interface universal para percorrer diferentes estruturas precisa ser fornecida na coleção.

Estrutura I

Participantes

IteradorIF define a interface para acessar e percorrer os elementos

IteradorConcreto Implementa a interface Iterator; Mantém o controle da posição corrente no percurso do agregado.

ColecaoIF define uma interface para a criação de um objeto Iterator.

ColecaoConcreta implementa a interface de criação do Iterador para retornar uma instância do

Vantagem I

Suporta variações na travessia, ou percurso, de uma coleção. Simplifica a interface para a coleção.

Iterador em java I

Abaixo seguem alguns códigos que exemplificam a navegação em coleções com e sem o uso de iteradores.

1 for ( int i = 0 ; i < MAXIMO ; i++ ){ 2 // trabalha com i

3 }

1 Object [] array = new Object [ 10 ]

2 for ( int i = 0 ; i < array.length ; i++ ){ 3 Object obj = array [ i ] ;

4 // trabalha com obj 5 }

Iterador em java II

1 ObjectGroup groupOfObjects = new ObjectGroup () ; 2 Iterator it = Iterator.iteratorFor ( groupOfObjects ) ; 3

4 while ( it.hasMore () ){ 5 Object obj = it.current () ; 6 // trabalha com obj

Padrão Mediator I

Um mediador é quem desacopla e gerencia as colaborações en-tre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo.

Padrão Mediator II

Normalmente, um programa é feito por um número muito grande de classes. Então, a lógica e o código são distribuídos entre es-sas classes.

Padrão Mediator III

No entanto, quanto mais classes houver no seu projeto, a co-municação entre essas classes será mais complexa. Isso faz com que a leitura e a manutenção do programa fique mais difícil, tal situação acarreta na dificuldade de mudanças no projeto, já que, uma simples mudança pode afetar todo o código e as outras classes.

Padrão Mediator IV

Com o padrão mediator, a comunicação entre os objetos é en-capsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando.

Definição I

Define um objeto que encapsula como um conjunto de obje-tos interage. O padrão Mediator promove um baixo acopla-mento evitando que os objetos façam referência uns aos outros de forma explícita, permitindo a você variar o uso da interação de forma independente.

O problema I

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?

Solução I

Introduzir um mediator: objetos podem se comunicar sem se conhecer.

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

Checklist I

1 Identificar uma coleção de objetos que interagem e que se

beneficiariam com o desacoplamento mútuo;

2 Encapsular essas interações na abstração de uma nova

classe;

3 Criar uma instância dessa nova classe e refazer todos os

’colegas’ de objetos para interagir com um único Mediador;

4 Equilibrar o princípio do desacoplamento com o princípio

da distribuição de responsabilidade de maneira uniforme;

Estrutura I

Participantes

Mediator define uma interface para comunicação com os objetos Colleague;

ConcreteMediator conhece as classes Colleague e mantém uma referência aos objetos Colleague. Ele implementa a comunicação e a transferência de mensagens entre as classes Colleague;

Classes Colleague mantêm uma referência ao seu objeto Mediator - se comunicam com o Mediator sempre que necessário. De outra forma, se comunicam com um Colleague.

Vantagens I

Desacoplamento entre os diversos participantes da rede de comunicação (participantes não se conhecem); Eliminação de relacionamentos muitos para muitos (são todos substituídos por relacionamentos um para muitos); A política de comunicações está centralizada no mediador e pode ser alterada sem mexer nos colaboradores.

Desvantagens I

A centralização pode ser uma fonte de gargalos de desempenho e de risco para o sistema em caso de falha; Na prática, os mediadores tendem a se tornar mais complexos.

Padrões relacionados I

Facade Um mediator simplificado torna-se um padrão Facade se o mediador for a única classe ativa e se as classes Colleagues forem classes passivas;

Adapter O padrão Mediator apenas media os pedidos entre as classes Colleague;

Observer Os padrões Mediator e Observer são semelhantes, resolvendo o mesmo problema.

Padrão Memento I

Memento é um padrão de projeto que permite armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário. Conhecido como Token.

Propósito I

Captar e externalizar um estado interno de um objeto, de ma-neira que esse estado seja restaurado ao objeto em outro mo-mento, sem violar seu encapsulamento.

Motivação I

Em programas de computador, nem sempre uma seqüência li-near e contínua de ações satisfaz as necessidades que um apli-cativo deve atender - principalmente quando se trata de contato direto com o usuário: ações como “desfazer” e “voltar” se fazem necessárias. Ainda, quando uma determinada situação desejada é obtida no sistema, é comum o desejo do usuário de armazenar resultados para usos posteriores.

Motivação II

Com este objetivo, se apresenta o padrão Memento com a fina-lidade de criar um repositório de informações sobre um objeto, que pode ser acessado tanto para guardar como para recuperar essas informações, que representam um estado de um objeto específico.

Motivação III

A maneira mais comum de guardar informações dessa maneira é através de um clone do objeto, instanciado com as informações do estado a ser guardado.

Motivação IV

Deste modo, não haverá exposição direta do estado interno do objeto, ou seja, não será violado o seu encapsulamento.

Aplicabilidade I

Na implementação de ações de “desfazer”;

Para o armazenamento de estados a serem restaurados de um objeto, como por exemplo, um banco de dados; Para a captação de estados de objetos que são encobertos por encapsulamento;

Estrutura I

Participantes

Objeto é o objeto que vai oferecer algum estado para ser guardado, possivelmente restaurado num

momento posterior. Seus estados só podem ser acessados por seus métodos (ou seja, o

encapsulamento é preservado).

Memento guarda e recupera estados do objeto especificado.

Cliente cria e faz uso de um objeto Memento,

instanciando-o e solicitando a este que guarde ou restaure um estado de uma instância de Objeto.

Padrão Observer I

O Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam noti-ficados e atualizados automaticamente.

Padrão Observer II

Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto. O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents.

Motivação I

Um objeto que possua agregações deve permitir que seus ele-mentos sejam acessados sem que a sua estrutura interna seja exposta.

De uma maneira geral pode-se desejar que estes elementos se-jam percorridos em várias ordens.

Motivação II

Como garantir que objetos que dependem de outro objeto per-cebam as mudanças naquele objeto?

Os observadores (observer) devem conhecer o objeto de interesse.

O objeto de interesse (subject) deve notificar os observadores quando for atualizado.

Motivação III

Os objetos devem-se interligar entre si de forma a que não se conheçam em tempo de compilação de forma a criar o acopla-mento e desfazê-lo a qualquer moacopla-mento em tempo de execu-ção. Solucionar isso fornece uma implementação muito flexível de acoplamento de abstrações.

Aplicabilidade I

O padrão Observer pode ser usado quando uma abstração tem dois aspectos, um dependente do outro. Encapsular tais aspec-tos em objeaspec-tos separados permite que variem e sejam reusados separadamente.

Quando uma mudança a um objeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar ou quando um objeto deve ser capaz de avisar outros sem fazer suposições sobre quem são os objetos. Em outras palavras, sem criar um acoplamento forte entre os objetos.

Padrão State I

State é um padrão de projeto de software usado para permi-tir que um objecto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe.

Padrão State II

O padrão State deve ser utilizado nas seguintes situações: O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado.

Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto.

Este estado é normalmente representado por uma ou mais constantes do tipo enumerado.

Frequentemente, vários métodos contém esta mesma estrutura condicional.

Propósito I

Permitir que um objeto altere seu comportamento se seu estado interno for alterado, parecendo como se o próprio objeto tivesse alterado sua classe.

Distribuir lógica específica de estado mediante classes que representem o estado de um objeto.

Motivação I

O estado de um objeto é uma combinação dos valores atuais dos seus atributos. Quando chamado um método set, tipicamente muda-se o estado do objeto, e este pode mudar o seu próprio estado enquanto seus métodos são executados.

Motivação II

Em alguns casos, o estado de um objeto pode ser um aspecto

proeminente do seu comportamento. A lógica que depende

desse estado pode espalhar-se por meio de muitos dos méto-dos da classe.

Motivação III

Para evitar esse espalhamento, pode-se mover o comportamento específico de estado para dentro de um grupo de classes, com cada uma representando um estado diferente.

Aplicabilidade I

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

Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso.

Um algoritmo utiliza dados que não são conhecidos ao cliente.

Estrutura I

Ao modelar um objeto cujo estado é importante, pode-se des-cobrir que há uma variável que monitora o modo como esse objeto deveria se comportar, dependendo do seu estado. Essa variável pode aparecer em comandos if complexos, em cascata, que focalizam como reagir aos eventos que o objeto pode ex-perimentar.

Estrutura II

Participantes

Contexto Define a interface de interesse para os clientes. Mantém uma instância de uma subclasse EstadoConcreto que define o estado corrente

Estado Define uma interface para encapsular o comportamento associado com um estado particular do contexto

EstadoConcreto Implementa um comportamento associado a um estado do Contexto.

Consequencias I

Mantém local o comportamento específico de estado e o comportamento das partições em diferentes estados. Torna explícitas quaisquer transições de estado.

Evita profundos ou complexos comandos if, dependendo, então, do polimorfismo para executar a correta

Padrão Strategy I

O objetivo é representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos. O padrão Strategy permite definir novas operações sem alterar as classes dos ele-mentos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo como uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam.

Propósito I

Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis

Strategy permite que algoritmos variem

Motivação I

Quando se necessita de um algoritmo que trata de modos dife-rentes os dados submetidos a ele.

Aplicabilidade I

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

Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso.

Um algoritmo utiliza dados que não são conhecidos ao cliente.

Estrutura I

Participantes

Estrategia define uma interface comum para todos os algoritmos suportados.

EstrategiaConcreta1 e EstrategiaConcreta2 implementa o algoritmo usando a interface de Estratégia.

Contexto É configurado com um objeto EstrategiaConcreta.

Mantém uma referência para um objeto EstrategiaConcreta.

Consequencias I

Vantagens

Famílias de algoritmos relacionados; Uma alternativa ao uso de subclasses; Eliminam comandos condicionais; Desvantagens

Padrão Template Method I

Um Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por Método abstratos. As subclas-ses devem se responsabilizar por estas partes abstratas, deste algoritmo, que serão implementadas, possivelmente de várias formas, ou seja, cada subclasse irá implementar à sua necessi-dade e oferecer um comportamento concreto construindo todo o algoritmo.

Padrão Template Method II

O Template Method fornece uma estrutura fixa, de um algo-ritmo, esta parte fixa deve estar presente na superclasse, sendo obrigatório uma classeAbstrata que possa conter um método concreto, pois em uma interface só é possível conter métodos abstratos que definem um comportamento, esta é a vantagem de ser uma Classe Abstrata porque também irá fornecer méto-dos abstratos às suas subclasses, que por sua vez herdam este método, por Herança (programação), e devem implementar os métodos abstratos fornecendo um comportamento concreto aos métodos que foram definidos como abstratos.

Padrão Template Method III

Com isso certas partes, do algoritmo, serão preenchidos por implementações que irão variar, ou seja, implementar um algo-ritmo em um método, postergando a definição de alguns passos do algoritmo, para que outras classes possam redefiní-los.

Padrão visitor I

Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera.

É uma maneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novas funcionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las.

Padrão visitor II

A idéia é usar uma classe de elementos como uma estrutura, sendo que cada uma delas possui um método cujo um dos ar-gumentos é um objeto do tipo visitor.

Padrão visitor III

Visitor é uma interface que possui um método visit() para cada classe de elementos. O método accept() de uma classe de ele-mentos invoca o método visit() de sua respectiva classe. Classes visitor concretas distintas podem então ser escritas para implementar operações especiais.

Padrão visitor IV

O padrão Visitor é uma solução para separar o algoritmo da estrutura. Uma das vantagens desse padrão é a habilidade de adicionar novas operações a uma estrutura já existente.

Padrão visitor V

Com ele, podemos ter a classe ObjetoSolido e o comportamento de queda em uma classe Gravidade, separada da estrutura do ObjetoSolido.

Padrão visitor VI

Isso é feito através de uma interface, onde o objeto que vai executar esse método da classe do comportamento, passa uma referencia dela mesmo junto dos parâmetros normais da classe.

Padrão visitor VII

Representa um método a ser executado sobre os elementos de uma estrutura de objetos. O padrão Visitor permite que se defina um novo método sem alterar as classes dos elementos sobre os quais o método age.

Padrão visitor VIII

Visitor promove a extensão de funcionalidades através da cri-ação de classes que obedeçam a uma interface comum. Esta interface, Visitor (Visitante), especifica sobre que objetos os métodos poderão ser executados, definindo um método visi-tar(ObjetoX o) para cada ObjetoX possível.

Padrão visitor IX

Os métodos são codificadas então em classes que implementam Visitante, o que permite que se crie novos métodos, mas não permite que se altere os objetos sobre os quais operam. Os objectos clientes criam o visitante que quiserem e chamam o método visitar() para o objecto sobre o qual pretendam operar.

Estrutura I

Participantes

Visitor Visitor o Declara o método visit para cada classe de ConcreteElement na estrutura de objectos. O nome do método e a assinatura, identificam a classe que envia o pedido visit ao Visitor Isso permite ao visitor determinar a classe concreta do elemento a ser visitado. Então o visitor pode aceder directamente aos elementos, através da sua interface particular.

Estrutura II

ConcreteVisitor Implementa os métodos declarados pelo Visitor. Cada método implementa um fragmento do algoritmo definido para a correspondente classe ou objecto na estrutura. ConcreteVisitor fornece o contexto para o algoritmo e armazena o seu estado local. Este estado, geralmente

acumula resultados durante a passagem pelos elementos da estrutura.

Element Define o método Accept que recebe um visitor como argumento.

ConcreteElement Implementa o método Accept que recebe um visitor como argumento.

Estrutura III

Pode fornecer uma interface de alto-nível, para permitir o visitor visitar os seus elementos.

Pode ser um padrão Composite ou uma collection - list ou set.

Outros padrões I

Booch coletou uma série de padrões, além dos previstos pelo GoF e pelo Grasp.

Eles podem ser vistos no link: http://www.dsc.ufcg.edu.br/ jac-ques/cursos/map/recursos/patterns.html