Is The Visitor Pattern Useful For Dynamically Typed Languages?

October 27, 2023 Post a Comment

The Visitor pattern allows operations on objects to be written without extending the object class. Sure. But why not just write a global function, or a static class, that manipulat

Solution 1:

The place where Visitor is particularly useful is where the Visitor needs to switch on the type of Visitees, and for whatever reason, you don't want to encode that knowledge into the Visitees (think plugin architectures). Consider the following Python code:

Visitor style

classBanana(object):defvisit(self, visitor):
          visitor.process_banana(self) 

classApple(object):defvisit(self, visitor):
          visitor.process_apple(self) 

classVisitorExample(object):defprocess_banana(self, banana):
          print "Mashing banana: ", banana

      defprocess_banana(self, apple):
          print "Crunching apple: ", apple

(Note that we could compress the visitee logic with a base class/mixin).

Compare with:

Non-visitor style

class NonVisitorVisitor(object):
      def process(self, fruit):
          verb = {Banana: "Mashing banana: ", 
                  Apple: "Crunching apple: "}[type(fruit)]
          print verb, fruit

In the second example, the fruits don't need any special support for the "visitor", and the "visitor" handles the absence of logic for the given type.

By contrast, in Java or C++ the second example is not really possible, and the visit method (in the visitees) can use one name to refer to all versions of the process method; the compiler will pick the version which applies to the type being passed; and the visitor can easily provide a default implementation for the root class for the type of visitees. It's also necessary to have a visit method in the visitees because the method variant (e.g. process(Banana b) vs process(Apple a)) is selected at compile time in the code generated for the visitee's visit method.

Accordingly, in languages like Python or Ruby where there is no dispatch on parameter types (or rather, the programmer has to implement it themselves), there is no need for the visitor pattern. Alternatively, one might say the visitor pattern is better implemented without the dispatching through visitee methods.

In general in dynamic languages like Python, Ruby, or Smalltalk, it is better to have the "visitee" classes carry all the information needed (here, the verb applicable), and if necessary, provide hooks to support the "visitor", such as command or strategy patterns, or use the Non-visitor pattern shown here.

Conclusion

The non-Visitor is a clean way to implement the type-switching logic, notwithstanding that explicit type switching is usually a code smell. Remember that the Java and C++ way of doing it is also explicit switching in the Visitor; the elegance of the pattern in those languages is that it avoids having explicit switching logic in the visitees, which is not possible in dynamic languages with untyped variables. Accordingly, the Visitor pattern at the top is bad for dynamic languages because it reproduces the sin which the Visitor pattern in static languages seeks to avoid.

The thing with using patterns is that rather than slavishly reproducing UML diagrams, you must understand what they are trying to accomplish, and how they accomplish those goals with the language machinery concretely under consideration. In this case, the pattern to achieve the same merits looks different, and has a different pattern of calls. Doing so will allow you to adapt them to different languages, but also to different concrete situations within the same language.

Update: here's a ruby article on implementing this pattern: http://blog.rubybestpractices.com/posts/aaronp/001_double_dispatch_dance.html

The double dispatch seems rather forced to me; you could just do away with it, as far as I can tell.

Solution 2:

This answer is made with an ignorance of PHP etc but the Visitor needs typically to call more than just a single method (you mentioned "serialize") on the entities. When the Visit() method is called on the concrete Visitor, the Visitor is capable of running distictly different code for each entity subtype. I don't see how that is different from a dynamically-types language (though I'd love some feedback).

Another nice benefit of Visitor is it provides a clean seperation of the code that is getting run on each entity from the code that enumerates the entities. This has saved me some serious code duplication in at least one large project.

As an aside, I've used Visitor in languages that did not have method overloading. You just replace Visit(TypeN n) with VisitN(TypeN n).

Follow up from comments.

This is a visitor psuedo code, and I don't know how I would so it without the cooperation of the visited object (at least without a switch block):

abstractclassScriptCommand
{
   voidAccept(Visitor v);
}

abstractclassMoveFileCommand
{
   string TargetFile;
   string DestinationLocation;

   voidAccept(Visitor v)
   {
      v.VisitMoveFileCmd(this);  // this line is important because it eliminates the switch on object type
   }
}

abstractclassDeleteFileCommand
{
   string TargetFile;

   voidAccept(Visitor v)
   {
      v.VisitDeleteFileCmd(this); // this line is important because it eliminates the switch on object type

   }
}

// etc, many more commandsabstractclassCommandVisitor
{
   voidVisitMoveFileCmd(MoveFileCommand cmd);
   voidVisitDeleteFileCmd(DeleteFileCommand cmd);
   // etc
}

// concrete implementationclassPersistCommandVisitor() inherits CommandVisitor
{
   voidVisitMoveFileCmd(MoveFileCommand cmd)
   {
      // save the MoveFileCommand instance to a file stream or xml doc// this code is type-specific because each cmd subtype has vastly// different properties
   }

   voidVisitDeleteFileCmd(DeleteFileCommand cmd)
   { 
      // save the DeleteFileCommand instance to a file stream or xml doc// this code is type-specific because each cmd subtype has vastly// different properties
   }

}

The visitor infrastructure allows the handling of a wide array of command subtypes with no select case, swithc, if else.

In regards to the visitor handling the enumerating, I think you are limiting yourself like that. That's not to say a cooperating class (an abstract VisitorEnumerator) can't be involved.

For example, note this visitor is unaware of the order of enumeration:

classFindTextCommandVisitor() inherits CommandVisitor
{
   string TextToFind;
   boolean TextFound = false;

   voidVisitMoveFileCmd(MoveFileCommand cmd){
      if (cmd.TargetFile.Contains(TextToFind) Or cmd.DestinationLocation.Contains(TextToFind))
         TextFound = true;
   }


   voidVisitDeleteFileCmd(DeleteFileCommand cmd){ 
      // search DeleteFileCommand's properties
   }

}

And this allows it to be reused like this:

ScriptCommand FindTextFromTop(string txt)
{
   FindTextCommandVisitor v = new FindTextCommandVisitor();
   v.TextToFind = txt;
   for (int cmdNdx = 0; cmdNdx < CommandList.Length; cmdNdx++)
   {
      CommandList[cmdNdx].Accept(v);
      if (v.TextFound)
         return CommandList[cmdNdx];  // return the first item matching
   }
}

and the enumerate the opposite way with the same visitor:

ScriptCommand FindTextFromBottom(string txt)
{
   FindTextCommandVisitor v = new FindTextCommandVisitor();
   v.TextToFind = txt;
   for (int cmdNdx = CommandList.Length-1; cmdNdx >= 0; cmdNdx--)
   {
      CommandList[cmdNdx].Accept(v);
      if (v.TextFound)
         return CommandList[cmdNdx];  // return the first item matching
   }
}

In real code I would create a base class for the enumerator and then subclass it to handle the different enumeration scenarios, while passing in the concrete Visitor subclass to completely decouple them. Hopefully you can see the power of keeping the enumeration seperate.

Solution 3:

I think you are using Visitor Pattern and Double Dispatch interchangeably. When you say,

If I can work with a family of heterogeneous objects and call their public methods without any cooperation from the "visited" class, does this still deserve to be called the "Visitor pattern"?

and

write a new class that manipulates your objects from the outside to carry out an operation"?

you are defining what Double dispatch is. Sure, Visitor pattern is implemented by double dispatch. But there is something more to the pattern itself.

Each Visitor is an algorithm over a group of elements (entities) and new visitors can be plugged in without changing the existing code. Open/Closed principle.
When new elements are added frequently, Visitor pattern is best avoided

Solution 4:

Maybe, it depends on the language.

The visitor pattern solves double and multiple-hierarchy problems in languages that don't feature multiple-dispatch. Take Ruby, Lisp and Python. They are all dynamically-typed languages, but only CLOS-Lisp implements multiple-dispatch in the standard. This is also called multimethods and Python and Ruby can apparently implement it by using extensions.

I like this curious comment on wikipedia stating that:

Lisp's object system [CLOS] with its multiple dispatch does not replace the Visitor pattern, but merely provides a more concise implementation of it in which the pattern all but disappears.

In other languages, even statically typed ones, you have to work around the absence of multimethods. The Visitor pattern is one such way.

Solution 5:

Visitor Pattern to me meant to add new functionality to objects based on their type. Apparently having if/else ladders to perform type specific operations is bad (I would like an explanation for this :( ). In python, I was able to do this, without the whole double dispatch drama, by monkeypatching (another bad idea) certain functions as class methods.

I asked about this here.

In the below example, assume there's a base class ASTNode and a large class hierarchy under it (ASTVar, ASTModule, ASTIf, ASTConst, etc). These classes only have their specific data attributes and trivial methods.

Then, assume the class code is locked (or maybe the functionality is separated from the data). Now, I have methods which are dynamically assigned to classes. Note that in below example the iteration/recursion method call name (stringify) is different from the function name (nodeType_stringify).

defASTNode__stringify(self):
    text = str(self)
    for child in self.children:
            text += ", { " + child.stringify() + " }"return text

defASTConst__stringify(self):
    text = str(self)
    for child in self.children:
            text += ", [ " + child.stringify() + " ]"return text

defASTIf__stringify(self):
    text = str(self)
    text += "__cond( " + self.op1.stringify() + ")"
    text += "__then { " + self.op2.stringify() + "}"
    text += "__else {" + self.op3.stringify() + "}"return text

I can extend the classes (possibly, one-time during module init) with functionality whenever I want (bad idea?).

# mainModule1.pydefextend_types():
    # ASTNode and all derived class get this method
    ASTNode.stringify = ASTNode__stringify
    ASTConst.stringify = ASTConst__stringify
    ASTIf.stringify = ASTIf__stringify

Now, calling my_root_node.stringify() would appropriately call the right child methods (recursively), without explicitly checking for type.

Isn't this technique be similar to adding methods to the Javascript prototypes (Visitor pattern in JS).

Wasn't this what the goal of Visitor Pattern was? Extension of code-locked Types? Surely, the need to use double-dispatch (VisitorObject.visit(ConcreteObject) being called by ConcreteObject.Accept(VisitorObject)) wouldn't be necessary in python, which is dynamically typed. Probably, someone will formalize this for dynamically typed languages, and we will have a new pattern on hand, or not. After all, patterns are discovered, not invented (I don't remember where I read this).

Python College