Lecture thumbnail 0:00 / 4:46 Welcome to the last section of this design Patterns course.
And in this section we’re going to talk about the visitor design pattern.
So what is the motivation behind using a visitor?
Well, the motivation is simple.
We need to define a new operation and we need to define it on an entire class hierarchy.
So if you imagine a base class, a bunch of descendants, a bunch of their descendants, you now need
to define a new operation.
So essentially a new method on every single element in this hierarchy.
So for example, let’s suppose you have a document model, so you have some sort of base document,
but then you have document descendants, and they are composed of all sorts of different parts and they
all play together in a really complicated composition.
And then you want to take the whole document and make it printable to a format like HTML or markdown.
Now you probably realize that in order to make the document printable, you have to take every single
part that can exist within a document and make that printable to HTML or markdown.
Now, we don’t want to keep modifying every class in the hierarchy, even though Resharper makes it
easy to add a method to every element in the hierarchy, you actually have to fill it in with meaning
and you have to be consistent about it.
And this is difficult.
So we need also in those implementations, we need access to the non-common aspects of the classes in
the hierarchy, because I know what you’re thinking.
You’re thinking, Hey, let’s just do an extension method on the top level class and let’s do everything
there.
But unfortunately, an extension method won’t do because you actually need access to the internals of
those classes.
So on the one hand, you want to be able to kind of get get the information from those classes.
On the other hand, you want it to be as general as possible and you want to implement this as quickly
as possible.
So an example would be something like if you want to make an external component to handle the rendering
of the different formats, for example, but you want to avoid writing lots of switches on types, switches
on types are of course possible.
You can write a massive switch statement where you check the variable against every single type in the
hierarchy, but that is error prone and difficult and not really a great way to go.
So this is where the visitor pattern comes in.
So the visitor design pattern is a very specific pattern.
It’s a pattern where you have a component which is called a visitor, which is actually allowed to traverse
the entire inheritance hierarchy.
And it’s typically implemented by having a single method, a single method called visit, typically
propagating throughout the entire hierarchy.
So you do have to modify the hierarchy.
But the key thing about this approach is you modify the inheritance hierarchy just once.
You add just a single method called visit, and that’s pretty much it.
And you only do it once and you never have to go back to the hierarchy again.
Of course, if you add additional elements to the hierarchy, those have to have that visit method as
well.
But apart from that, there is really no requirements because this visit method is just a placeholder.
And the reason why it exists in the first place is to allow something called double dispatch.
Now, in order to talk about double dispatch, we need to talk about what dispatch actually is.
So dispatch basically answers a single question which function are we going to call?
So for example, you have a dot f of B, so you have a function call on an object of type A, which
is called maybe small A, and the function name is B, and there is an argument there.
Now we have different forms of dispatch.
And typically what you have in this kind of call is called single dispatch.
So single dispatch is where the method that’s going to be called depends on the name of the request
and the type of the receiver.
So if you’re calling something on an object of type foo, for example, you know the receiver is foo
and the name of the request is typically the name of the method.
Now let’s not forget that you can overload the different methods, so that’s a possibility.
But apart from that, you don’t really get that much flexibility.
So what the visitor design pattern does is it does something called double dispatch.
Now double dispatch is a trick and it does a double hop of methods, as we’re going to see.
But in this case, what happens is that the invocation, the actual method which gets invoked, depends
on the name of request, and it also depends on the type of two receivers.
So now the method that’s going to be called depends not just on the type of element that is being visited
in our case, but also the type of visitor.
So I understand that it’s still a little bit cryptic, so the best way to appreciate it is to actually
look at the source code, and that way you will figure out better what’s actually going on.
Stop Play Play Play Play Play Play Play Start Play information alert