A rootin', tootin' new article entitled "Generifying your Design Patterns -- Part I: The Visitor", written by our own Mark Spritzler, appears in the latest issue of the JavaRanch Journal. You kin check out that there article here. Y'all have anything to say about it? Say it right in this thread!
Mhh, that pattern misses half of what the Visitor pattern is about, it seems to me: adding an operation to a class *hierarchy*.
Consequently, when I use the Visitor pattern, it typically has more than one visit method - one for every subtype. Using generics won't work any longer in those cases, as far as I can see.
So I'd say that the article talks about a kind of a degenerated Visitor - perhaps it would be better to call it a Strategy?
Generics are also useful for Visitors, though:
Quite often I use Visitors to decouple domain classes from the view. For example, let's say that we want to show different subclasses in a hierarchy as different icons in a view. Selecting the icons could be done using a Visitor - but as a Visitor typically can't return something, the question is where to remember the icon. You need to use some kind of workaround - my preferred way is using local classes:
I haven't tried it yet (not using Java 5 at work yet), but using generics, the following should work:
(I hope I got the syntax right...)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Yes it does, it is not the true Visitor pattern, it is a modified version and the article states that. There isn't as much to gain with the real Visitor pattern and generics. The visitor itself couldn't be generified because of erasure, and Jim makes a good comment on it in the article. On the object that has the accept method, that can have a generic interface, and in the next article in the series I start off with that version, then go into another pattern.
Originally posted by Mark Spritzler: Yes it does, it is not the true Visitor pattern, it is a modified version and the article states that.
Ah, sorry, I only skimmed over the article, and should have said so.
I'm a little bit disappointed that we seem to agree - it feels like a missed opportunity for a lively discussion...
Joined: Jul 11, 2001
Originally posted by Kishore Dandu: can some one explain to me real world uses of this visitor and semi-visitor(mark spitzerized) patterns.
Take my example above. Foo1 and Foo2 are business classes in the Foo class hierarchy. If I want them to be displayed with different Icons, one way to do that would be to add a getIcon method to the classes and implement it polymorphically.
But typically I don't want business classes to know about GUI stuff such as Icons, because it violates the Single Responsibility Principle.
One alternative would be to use something if-else chains to select the icon. The Visitor pattern replaces such code, with the advantage of enhanced compiler support.
Imagine that I have several such Visitors (one for selecting Swing Icons, one for selecting Web Icons, one for persistence in a database, etc. pp.). Now I introduce another class, Foo3.
With the if-else code, I manually have to find all the places where I have to take care of handling this new class. With Visitor, I have full support of the compiler: first, it forces me to implement the accept method in Foo3. That method will include a call to visitFoo3 on the visitor, which forces me to declare that method on the visitor interface. Which in turn forces me to implement the method in all visitor implementations. Voila...
Joined: Jul 11, 2001
Regarding the semi-visitor, I assume that it's mainly useful for the implementation of Internal Iterators. But Mark will probably be in a better position to comment...
In our case, we had an Order coming in through EDI and a Web Service, so the Order was in XML then converted into the Object Model.
After we receive it, we have to validate it. There are a few different validations that we needed to create. So, like Ilja, had said, the design in the document is a cross of Visitor/Strategy/Command. So each Visitor is code to validate a part of the Object Model. So in the article's version, the Visitor is of a specific type and can only validate those types. And the actual Type can only accept Visitors of that type.