Examining the strengths of the visitor patter and it’s appropriate usage.
Because object-oriented design is awesome and there’s much to learn, here’s a look at the implementation and advantages of the visitor pattern. The visitor pattern is used to easily add functionality to classes without needing to mess with the base classes themselves. There’s a nice clean layer of separation between the core classes and the logic.
The examples we’ll use are a couple animal objects – a dog and a gecko. For this demo these animals only do two things:
Return a value for how cool they are.
Return a value for how useful they are in battle.
Here’s that program with polymorphism through inheritance. It’s as simple as you would expect, nothing real exciting.
So why improve upon that? It’s a clean, concise example that does the job well. Consider, though, if these animal’s characteristics and actions were liable to change. If we needed to give the animals the ability to speak (assuming the noise is unique) there would have to be a speak() method added in EVERY class of animal. Making edits in so many places is not only tedious, but editing an already solid core class comes with the unnecessary risk of breaking existing functionality.
The visitor pattern aims to fix these issues. It’s also a form of polymorphism that utilizes something called “double dispatching”. The double dispatch is a double message send between two classes – the visitor and the class being visited. These message sends allow all of the logic in the core classes to be factored out into a completely separate Visitor class. To add functionality to the objects we’d just create another Visitor class. It’s clean and safe. And here’s that program!
So at first it might look a bit unappetizing – there are more lines of code and more classes; it feels overly complicated. The cool part comes in when we want to add functionality to the animal classes. Using inheritance alone required us to edit each animal class, but using the visitor pattern allows us to just add a separate single class. There is no risk of us breaking any of the existing code, we don’t even touch it.
And now our animals speak!
It’s important to understand that the visitor pattern isn’t all golden though. Like everything else, it’s just another tool and has a time and place. In this example we assume a static set of core classes and changing functionality. If we flipped the environment and were dealing with an ever-changing set of objects with mostly consistent methods the visitor pattern becomes the opposite of what we want.