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

[Ernest Friedman-Hill]

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]

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:

class SelectIconVisitor implements FooVisitor {
  Icon icon;
  public void visitFoo1() {
    icon = new Foo1Icon();
  }
  public void visitFoo2() {
    icon = new Foo2Icon();
  }
}
SelectIconVisitor visitor = new SelectIconVisitor();
myFoo.accept(visitor);
return visitor.icon;

I haven't tried it yet (not using Java 5 at work yet), but using generics, the following should work:

return myFoo.accept<Icon>(new FooVisitor<Icon> {
  public Icon visitFoo1() {
    return new Foo1Icon();
  }
  public Icon visitFoo2() {
    return new Foo2Icon();
  }
});

(I hope I got the syntax right...)

[Mark Spritzler]

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]

can some one explain to me real world uses of this visitor and semi-visitor(mark spitzerized) patterns.

Thanks in advance.

[Ilja Preuss]

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]

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]

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]

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]

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]

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