Co-writes we seem to have reached the last pattern of this entire course and that is of course the visitor
pattern not the simplest pattern out there.
So we're going to finish the course on a high note by looking at something reasonably complicated shall
we say.
So what does the visit are all about.
Well let's imagine that you have some hierarchy of classes.
Let's suppose that you have a hierarchy of document elements and you need to define some new operation
on the brand new operation that hasn't been there before.
So for example we have a document model and now you want that document model to be printable.
So you have this brand new concern of printing and you want to somehow propagate this through the entire
hierarchy by making essentially every single element of your document to be independently principals
somehow.
Now what you don't want to do is you don't want to go back into the existing code and modify each element
in Harkat and to be honest the first example that we're going to do is actually an example where we're
going to do exactly that.
But unfortunately this breaks a couple of principles so first of all the open closed principle which
we shouldn't forget about basically the idea that if you if you have existing code that you've already
tested you don't go back into that code to modify it if you can avoid it.
If you can for example use inheritance instead.
There's also the Single Responsibility Principle.
If you are introducing a brand new concern such as printing that particular part should be separate.
So that's the single responsibility principle here and that's generally just a better idea to have extensibility
on the side rather than a kind of intrusive approach.
So the downside of all of this is that we generally need access to the Norm Coleman aspects of all of
the different elements in the Harkee So for example if you have a an object oriented representation
of a document for example so you have list you have paragraphs and whatever you cannot give all of those
elements a single unified interface that allows you to access every single component.
That's simply not going to work so you need access to the kind of class specific elements.
Shall we say so you come of just go ahead and make a single interface for everything.
And what you want to do is you want to create an external component So for example in the case of a
document you want to create a an external component that will take an entire document like a really
big tree and it will actually print the whole thing and you want to avoid type checks if you can because
certainly some of the stuff can be built on the basis of a dynamic cast basically checking what type
of code you're actually getting what type of element you're on right now and then casting to to the
appropriate type with dynamic cast checking the pointer and then operating on that pointer but it's
not an approach which scales especially as you expand the set of elements that you're processing and
it's just difficult but we're going to take a look at that as well.
That's what I call the reflective approach.
So the visitor on the classic implementation of a visitor is a pattern where you have some component
which we call a visitor is allowed to traverse the entire inheritance Hark it is typically implemented
by you still have to be implemented by having something in the hierarchy and that's typically just a
single method though so instead of implementing one method per visitor you just implement a single method
called visit in the entire hierarchy.
And from then on you don't have to touch the hierarchy anymore.
So the hierarchy can exist on its own and you can create extra visitors sort of on the side which is
perfectly consistent with both the open closed principle as well as the single responsibility principle.