Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

New Article: Generifying your Design Patterns -- Part I: The Visitor

 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...)
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Mark
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
can some one explain to me real world uses of this visitor and semi-visitor(mark spitzerized) patterns.

Thanks in advance.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kishore Dandu:
can some one explain to me real world uses of this visitor and semi-visitor(mark spitzerized) patterns.


Visitor:

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...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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...
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

Mark
 
Anne Forumer
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am getting the following error on OrderDetail Class declaration!

The type GenerifiedVisitable is not generic; it cannot be parameterized with arguments <OrderDetail>

How can I fix this?

Thanks
 
Anne Forumer
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I fixed it by moving the Type parameter from the method to interface declaration.

In any case, that turned out to be moot point as there are many other errors in code which you never claimed was working code. In any case, I learned a lot from this example.

Thanks
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic