{"id":1790,"date":"2019-04-13T08:34:22","date_gmt":"2019-04-13T08:34:22","guid":{"rendered":"http:\/\/demensdeum.com\/blog\/?p=1790"},"modified":"2024-12-16T22:32:38","modified_gmt":"2024-12-16T19:32:38","slug":"visitor-pattern","status":"publish","type":"post","link":"https:\/\/demensdeum.com\/blog\/pt\/2019\/04\/13\/visitor-pattern\/","title":{"rendered":"Padr\u00e3o de visitante"},"content":{"rendered":"

Neste post irei descrever um padr\u00e3o de design chamado “Visitante” ou “Visitante”
<\/em>Este padr\u00e3o pertence ao grupo de Padr\u00f5es de comportamento<\/strong>.<\/p>\n

Vamos encontrar um problema<\/h3>\n

Esse padr\u00e3o \u00e9 usado principalmente para contornar a limita\u00e7\u00e3o do envio \u00fanico em linguagens de liga\u00e7\u00e3o antecipada.<\/p>\n

\"\"<\/a><\/p>\n

Alice X<\/a> por NFGPhoto<\/a> (CC-2.0<\/a>)
Vamos criar uma classe\/protocolo abstrato Band, fazer uma subclasse de MurpleDeep, criar uma classe Visitor com dois m\u00e9todos – um para enviar qualquer descendente de Band para o console, o segundo para gerar qualquer MurpleDeep, o principal \u00e9 que os nomes (assinaturas) dos m\u00e9todos sejam os mesmos e os argumentos diferem apenas por classe. Usando o m\u00e9todo de impress\u00e3o intermedi\u00e1rio com o argumento Band, criamos uma inst\u00e2ncia de Visitor e chamamos o m\u00e9todo visit para MurpleDeep.
Abaixo est\u00e1 o c\u00f3digo em Kotlin:

\n