{"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\/hi\/2019\/04\/13\/visitor-pattern\/","title":{"rendered":"Visitor pattern"},"content":{"rendered":"

In this note I will describe a design pattern called “Visitor” or “Visitor”
<\/em>This pattern belongs to the group of Behavioral patterns<\/strong>.<\/p>\n

Let’s think of a problem<\/h3>\n

This pattern is mainly used to work around the single dispatch limitation in early-binding languages.<\/p>\n

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

Alice X<\/a> by NFGPhoto<\/a> (CC-2.0<\/a>)
Let’s create an abstract class\/protocol Band, make a subclass MurpleDeep, create a class Visitor with two methods – one for outputting to the console any descendant of Band, the second for outputting any MurpleDeep, the main thing is that the names (signatures) of the methods are the same, and the arguments differ only in the class. Through the intermediate method printout with the argument Band, create an instance of Visitor and call the visit method for MurpleDeep.
Next is the code in Kotlin:

\n