Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

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

 
author and iconoclast
Posts: 24204
44
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...)
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Whatever you say buddy! And I believe this tiny ad too:
free, earth-friendly heat - a kickstarter for putting coin in your pocket while saving the earth
https://coderanch.com/t/751654/free-earth-friendly-heat-kickstarter
reply
    Bookmark Topic Watch Topic
  • New Topic