DESIGN PATTERN #9: VISITOR

OBJETIVO

• MUDAR OU ACRESCENTAR OPERAÇÕES FEITAS AOS ELEMENTOS DE UMA ESTRUTURA DE OBJETOS SEM MUDAR O CÓDIGO DAS CLASSES DOS ELEMENTOS

• O "VISITANTE" ACABA REPRESENTANDO UMA OPERAÇÃO A SER FEITA NOS ELEMENTOS DE UMA ESTRUTURA DE OBJETOS

MOTIVAÇÃO

• CONSIDERE UM COMPILADOR QUE REPRESENTE PROGRAMAS COMO ÁRVORES DE SINTAXE

• ESTRUTURALMENTE, TEMOS MUITOS TIPOS DE NODOS NA ÁRVORES (REFERÊNCIA A VARIÁVEL, ATRIBUIÇÃO, CHAMADA DE FUNÇÃO, ETC).

• ALGORITMICAMENTE, TEMOS MUITOS TIPOS DE OPERAÇÕES A FAZER NA ESTRUTURA DE OBJETOS

  • VERIFICAÇÃO DE TIPOS

  • GERAÇÃO DE CÓDIGO

  • OTIMIZAÇÃO DE CÓDIGO

  • IMPRESSÃO (PRETTY PRINTING) PARA DEPURAÇÃO

  • VERIFICAR SE VARIÁVEIS SÃO INICIALIZADAS ANTES DE USADAS

• OBSERVE QUE CADA OPERAÇÃO É IMPLEMENTADA DE FORMA DIFERENTE EM CADA TIPO DE NODO DA ESTRUTURA

• A QUESTÃO BÁSICA É QUE ESPALHAR O CÓDIGO DAS OPERAÇÕES NAS VÁRIAS CLASSES DOS NODOS LEVA A UM SISTEMA QUE É DIFÍCIL DE ENTENDER E MUDAR.

  • É CONFUSO TER NA MESMA CLASSE CÓDIGO DE VERIFICAÇÃO DE TIPOS, GERAÇÃO DE CÓDIGO, ETC.

  • ADICIONAR UMA NOVA OPERAÇÃO VAI LEVAR A MUDANÇAS A TODAS A CLASSES (E SUA RECOMPILAÇÃO)

• QUEREMOS UMA SOLUÇÃO QUE:

  • PERMITA ADICIONAR NOVAS OPERAÇÕES SEPARADAMENTE (NUMA NOVA CLASSE) SEM AFETAR TODAS AS CLASSES

  • MANTANHA A INDEPENDÊNCIA ENTRE AS CLASSES ESTRUTURAIS E AS OPERAÇÕES APLICADAS A ELAS

• A SOLUÇÃO É DE EMPACOTAR OPERAÇÕES RELACIONADAS NUM OBJETO SEPARADO CHAMADO UM "VISITOR" E PASSANDO ESTE OBJETO AOS ELEMENTOS DA ESTRUTURA (A ÁRVORE DE SINTAXE)

  • QUANDO UM ELEMENTO "ACEITA" O VISITANTE, ELE ENVIA UMA MENSAGEM A ELE PARA QUE FAÇA A OPERAÇÃO ADEQUADA PAR O TIPO DE OBJETO SENDO VISITADO

• EXEMPLO: O COMPILADOR CRIA UM VISITANTE DE VERIFICAÇÃO DE TIPOS E CHAMA A OPERAÇÃO "ACCEPT" DA ÁRVORE DE SINTAXE PASSANDO O VISITANTE COMO PARÂMETRO

  • CADA NODO IMPLEMENTA ACCEPT PELA CHAMADA DE UM MÉTODO PARTICULAR DO VISITANTE (UM NODO DE ATRIBUIÇÃO CHAMARIA visitaAtribuição())

  • O QUE SERÁ FEITA NESTA ROTINA (POLIMÓRFICA) DEPENDE DO TIPO DE VISITANTE QUE TEMOS

• PARA TERMOS UMA SOLUÇÃO MAIS GERAL, USAMOS UMA CLASSE ABSTRATA PARA VISITANTES QUE 'DECLARRA UMA OPERAÇÃO PARA CADA TIPO DE NODO

  • VISITANTES CONCRETOS ENCAPSULAM AS ROTINAS RELACIONADAS COM DETERMINADA OPERAÇÃO (VERIFICAÇÃO DE TIPOS, ETC.)

HIERARQUIA DE VISITANTES (ACIMA) E DE ELEMENTOS (ABAIXO)

• OBSERVE QUE USANDO O PADRÃO VISITOR, HÁ DUAS HIERÁRQUIAS DE CLASSES: OS ELEMENTOS DA ESTRUTURA E OS VISITANTES

  • UMA NOVA OPERAÇÃO É IMPLEMENTADA COM UMA NOVA SUBCLASSE DA HIERARQUIA DE VISITANTES

APLICABILIDADE

• USE O PADRÃO VISITOR QUANDO

  • 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 MATENHA NUMA ÚNICA CLASSE

  • AS CLASSES QUE DEFINEM A ESTRUTURA DE OBJETOS RARAMENTE MUDA MAS VOCÊ FREQUENTEMENTE TEM QUE CRIAR NOVAS OPERAÇÕES PARA A ESTRUTURA

    • SE A ESTRUTURA DE OBJETOS MUDA COM FREQUÊNCIA, É MELHOR DEIXAR AS OPERAÇÕES NAS CLASSES DOS OBJETOS DA ESTRUTURA

ESTRUTURA

CONSEQUÊ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 ElementosConcretos É 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
• VISITAS EM HIERARQUIAS DIFERENTES DE CLASSES
  • EMBORA O PADRÃO ITERADOR POSSA SER USADO PARA VISITAR OBJETOS DE UMA ESTUTURA E CHAMAR OPERAÇÕES PARA CADA ELEMENTO, O ITERADOR DEVE NECESSARIAMENTE VISITAR ELEMENTOS COM CLASSES RELACIONADAS (DE UMA MESMA HIERARQUIA)
  • UM VISITANTE NÃO TEM ESTE PROBLEMA. PODE HAVER UMA OPERAÇÃO ABSTRATA PARA CADA CLASSE, MESMO NÃO ESTANDO RELACIONADAS
• ACÚMULO DE ESTADO
  • VISITANTES PODEM ACUMULAR ESTADO AO VISITAR ELEMENTOS DE UMA ESTRUTURA. O ESTADO É ARMAZENADO DENTRO DO PRÓPRIO VISITANTE
• QUEBAR DE ENCAPSULAMENTO
  • PARA QUE O VISITANTE FAÇA SEU TRABALHO EM CIMA DE UM ELEMENTO, PODE SER OBRIGADO A "ABRIR" A INTERFACE DAS CLASSES DOS OBJETOS MANIPULADOS MAIS DO QUE SERIA DESEJÁVEL

DETALHES DE IMPLEMENTAÇÃO

• DOUBLE-DISPATCH
  • NA SOLUÇÃO ORIGINAL (SEM PADRÃO VISITOR), FAZEMOS DISPATCH SIMPLES. ISTO SIGNIFICA QUE A OPERAÇÃO FEITA DEPENDE DA OPERAÇÃO CHAMADA (NOME DO MÉTODO) E DO TIPO DO RECEPTOR
  • EXEMPLO: nodo n; n.verificaTipo()
    AQUI, A ROTINA CHAMADA É VerificaTipo() DA CLASSE DO NODO N.
  • COM O PADRÃO VISITOR, TEMOS DOUBLE DISPATCH POIS A OPERAÇÃO CHAMADA DEPENDE DO TIPO DE OPERAÇÃO (O NOME DO MÉTODO) E DO TIPO DE DOIS RECEPTORES (O OBJETO VISITADO E O PRÓPRIA VISITANTE)
  • EXEMPLO: n.accept(visitante)
    AQUI, A OPERAÇÃO VAI SOFRER UM DISPATCH ADICIONAL (ATRAVÉS DE accept()) E A OPERAÇÃO FINAL DEPENDERÁ DO TIPO DE n E DO TIPO DE visitante.
• QUEM É RESPONSÁVEL PELA NAVEGAÇÃO NA ESTRUTURA DE OBJETOS?
  • PODE SER A PRÓPRIA ESTRUTURA (SEMELHANTE A UM ITERADOR INTERNO)
  • PODE-SE USAR UM ITERADOR (EXTERNO)
  • PODE COLOCAR A NAVEGAÇÃO NO PRÓPRIO VISITANTE
    • ADEQUADO QUANDO O CAMINHAMENTO É MUITO COMPLEXO OU QUANDO O CAMINHAMENTO DEPENDE DO QUE OCORRE NAS VISITAS)

CÓDIGO

• FALTANDO AINDA :-)