my dog learned polymorphism*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Learning Visitor Design Pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Learning Visitor Design Pattern" Watch "Learning Visitor Design Pattern" New topic
Author

Learning Visitor Design Pattern

Abu Nene
Ranch Hand

Joined: Nov 13, 2008
Posts: 56
Hi I'm trying to understand visitor design pattern and written the following codes. Is there any concern on the codes?

Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1753
    
    7

Well, the code you provided won't compile, because of serveral issues, but the basic structure of the visitor pattern looks alright, except for the Visitor interface not supporting Element types. The whole Visitor approach is also a little redundant in your current Demo setup.

The idea behind the Visitor pattern is that you can use a Visitor implementation to execute an algorithm that is specific to the type of the object visited, while iterating a collection of objects of a disparate types that all belong to the same type-hierarchy. If you'd change the Visitor interface and the AreaVisitor class to support the base Element type, and if you'd create another Element subtype that doesn't provide the getArea() method you'd have a more complete type-hierachy to work with. You could then change the Demo class to build up a List of Elements that contains both instances of this new Element subclass and instances of Circle. Iterating that List and calling the accept(Visitor) method for each Element would be a better demonstration of how the Visitor pattern works.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
harshvardhan ojha
Ranch Hand

Joined: Jul 26, 2007
Posts: 157
    
    1

- how come it is abstract and also have body?
- you cant instantiate interface it must be an implementation.

If i am not considering you syntax, else everything seems fine to me. If you need to add some new operation for a new set of objects then you can add in your abstract class and objects will have it. But consider using reflection to visit.

use object.getClass() and visit only the desired objects.

Hope this will help.
Abu Nene
Ranch Hand

Joined: Nov 13, 2008
Posts: 56
harshvardhan ojha wrote: - how come it is abstract and also have body?
- you cant instantiate interface it must be an implementation.

If i am not considering you syntax, else everything seems fine to me. If you need to add some new operation for a new set of objects then you can add in your abstract class and objects will have it. But consider using reflection to visit.

use object.getClass() and visit only the desired objects.

Hope this will help.


Sorry type out of my head. Changed the codes with your comments. Is there a submit button build-in java compiler check somewhere?
Abu Nene
Ranch Hand

Joined: Nov 13, 2008
Posts: 56
Jelle Klap wrote:Well, the code you provided won't compile, because of serveral issues, but the basic structure of the visitor pattern looks alright, except for the Visitor interface not supporting Element types. The whole Visitor approach is also a little redundant in your current Demo setup.

The idea behind the Visitor pattern is that you can use a Visitor implementation to execute an algorithm that is specific to the type of the object visited, while iterating a collection of objects of a disparate types that all belong to the same type-hierarchy. If you'd change the Visitor interface and the AreaVisitor class to support the base Element type, and if you'd create another Element subtype that doesn't provide the getArea() method you'd have a more complete type-hierachy to work with. You could then change the Demo class to build up a List of Elements that contains both instances of this new Element subclass and instances of Circle. Iterating that List and calling the accept(Visitor) method for each Element would be a better demonstration of how the Visitor pattern works.


Hi Jelle, thanks for your reply. Not sure I'm getting you, can you explain more. Updated my codes, are you saying that my codes should be the following to illustrate the purpose of the visitor pattern?

Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1753
    
    7

Not exactly what I had in mind, but yes this would be a better demontration of the Visitor pattern than your initial code was.
Although the Visitor interface and the Element interface are still out-of-sync, as an Element can accept a Visitor, but a Visitor can't visit an Element.
Also, this code doesn't compile because the Visitor interface must declare a visit() method that accepts a Triangle, and there are a few other compilation issues besides that.
Please do try to post code that compiles
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Learning Visitor Design Pattern
 
Similar Threads
Polymorphism and Method Signatures
Tell don't ask and model view seperation
Visitor - decorator problem
Inheritance
the first code on interface