For a long time I’ve tried to get my head wrapped around the visitor pattern, and somehow this thing keeps being rather fuzzy to me.
I’m currently under the impression it is only useful to apply operations on objects that implement the Composite pattern. At least as far as PHP is concerned. Is that an accurate observation, or am I missing something?
I’m in the process of reimplementing some functionality, and this includes computing a diff between two Entities. These Entities contain various value objects. Different derivatives in the type hierarchy of these Entities have different value objects. Originally the diff code was contained in the entities themselves, though this caused quite some clutter, so I’d rather move it out into dedicated service objects. The Visitor pattern sprung to mind, though I do not see how I can actually sanely apply it. Would all the value objects need to implement some EntityElement interface? That seems bad. Is this a case where the Visitor pattern indeed does not apply, or am I simply failing to see how it would be applied nicely here?
1
In a strongly-typed language, Visitor is useful because of “double-dispatch”. Two objects of different types can interact without knowing what their types are. So it solves the “handshake problem”: if I have a bunch of known types, I can have every type in the bunch shake hands with every other type. The magic it does to do that is double-dispatch: I call you, passing along important information without knowing your type, and then you call me back, adding your own information. Now everyone has contributed their part without revealing what type they are.
In a dynamically-typed language, I agree it doesn’t seem like there’s much point. There are simpler ways to traverse an object structure.
In a dynamic language, you might end up with a simplified version of Visitor that leaves out the double-dispatch.
In the case you mentioned, diff is a natural candidate for Visitor, because it has that “handshake problem”: you have a bunch of types, and you want to diff any two of them. The simplification is that each class just needs to have a diff(other) method and a diff(value) method. The trick is that value doesn’t have to be an integer — it could be a more complex type. diff(other) would just be return other.diff(my_value). That’s the double-dispatch part, which does the trick of hiding the internals of the class.
…
The only other pattern that comes to mind would be a “parametric polymorphism” soultion. You have a Diff class, and each class you have returns has a Diff diff() method. The Diff class contains whatever information you need to do the diff — maybe just an int — and its a common class that takes the specific types out of the equation. So it would look something like
Diff d = a.diff().apply(b.diff())
If Diff really does just contain some value, then what you’re really doing is putting the different objects on a number line, and you could just have that value as a property. E.g. a.scale() or a.rank()
doOperation() = accept(), Element = Component
The difference is in the ObjectStructure in diagram 2. The Visitor Pattern does not require the ObjectStructure to implement the << interface >> Component. (Read below)
Often it is useful to let the ObjectStructure implement the Component interface in case you have a tree or other nested collections.
Sometimes you do not need an ObjectStructure to implement the Component interface. If the ObjectStructure is a simple collection, such as an array or a list, you know how to iterate over it. No need to add an accept() method to the ObjectStructure. It is the starting point of your visit.