Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When programming at work we now and then face a problem with visitors and module/project dependencies.

Say you have a class A in a module X. And there are subclasses B and C in module Y. That means that module Y is dependent on module X. If we want to implement a visitor pattern to the class hierarchy, thus introducing an interface with the handle Operations and an abstract accept method in A, we get a dependency from module Y to module X, which we cannot allow for architectural reasons.

What we do is, use a direct comparison of the types (i.e. instanceof, since we program in Java), which is not satisfying.

My question(s) would be: Do you encounter this kind of problem in your daily work (or do we make poor architectural choices) and if so, how is your approach to solve this?

Here is a minimal example in Java to illustrate my point. Package a has ClassA and the Visitor-Interface over the ClassA Hierarchy:

package pkg.a;  
public abstract ClassA extends ClassA {  
    public abstract void accept(ClassAVisitor visitor);  
   /* other methods ... */   
} 

package pkg.a;  
import pkg.b.ClassB;
import pkg.b.ClassC;
public interface ClassAVisitor {  
    public abstract void handle(ClassB visitee);
    public abstract void handle(ClassC visitee);  
} 

Package b has the concrete classes that extend from ClassA:

package pkg.b;  
import pkg.a.ClassAVisitor;
public ClassB extends ClassA {  
    public void accept(ClassAVisitor visitor) {  
        visitor.handle(this);  
    }   
} 

package pkg.b;
import pkg.a.ClassAVisitor;  
public ClassC {  
    public void accept(ClassAVisitor visitor) {  
        visitor.handle(this);  
    }   
}

Package a and b have a cyclic dependency.

share|improve this question
    
To clarify: Are you trying to implement a Visitor method in class A or a Visitor class V in module X? –  pdr Oct 31 '12 at 10:26
    
You can try to resolve the cyclic dependency by introducing a third module Z, which both X and Y depend on. This is possible if interfaces for A, B and C can be moved to Z. Otherwise it seems impossible. –  lorus Oct 31 '12 at 10:33
    
@pdr I want to "visit over" the class hierarchy of A. A would need an abstract accept Operation having the visitor interface as a parameter, but this means, that A, through the parameter, now knows about all its subclasses, thus having an unwanted cyclic dependency. –  Benjamin Rogge Oct 31 '12 at 10:38
1  
@BenjaminRogge: That really isn't the purpose of a Visitor pattern. Visitor is for situations where you're doing similar things to many disparate classes and you want to keep that code in one place. I suggest you rewrite your question to be more clear. –  pdr Oct 31 '12 at 10:42
1  
@pdr No. You are wrong. What benjamin is describing is a Visitor Pattern. –  Euphoric Oct 31 '12 at 12:05
show 4 more comments

4 Answers

up vote 1 down vote accepted

What about changing the visitor interface to remove the dependency from a to b?

package pkg.a;  
public abstract ClassA extends ClassA {  
    public abstract void accept(ClassAVisitor visitor);  
   /* other methods ... */   
} 

package pkg.a;  
public interface ClassAVisitor {  
    public abstract void handleB(ClassA visitee);
    public abstract void handleC(ClassA visitee);  
} 

and then

package pkg.b;
import pkg.a.ClassAVisitor;
public ClassB extends ClassA {
    public void accept(ClassAVisitor visitor) {
        visitor.handleB(this);
    }
}

package pkg.b;

import pkg.a.ClassAVisitor;
public ClassC {
    public void accept(ClassAVisitor visitor) {
        visitor.handleC(this);
    }
}
share|improve this answer
    
You would have to cast the object in the implementation of the handle operations, but it is still a solution, that will work for me. –  Benjamin Rogge Nov 16 '12 at 15:41
    
@Benjamin Rogge: I am afraid that you cannot avoid the cast: either you use the cast in the visitor implementation, or you import the subclasses in the package in which the visitor interface is defined (which creates your cyclic dependencies). –  Giorgio Nov 16 '12 at 16:01
add comment

You should be aware, that by implementing visitor, you are severely limiting yourself in how and where you can subclass root of the hiearchy. Your problems are results of such limitations.

Maybe you could make abstract BBase and CBase classes in module X and derive B and C classes from those. Then the whole visitor hiearchy can be in module X and module Y will only have concrete implementation of B and C classes. But this solution is also limited, because your visitor cannot work with any types, that are referenced in Y but not in X.

share|improve this answer
add comment

This seems pretty simple to me. You have three ways to avoid the circular dependency. You can merge A and B into a single package. You can move the visitor to package B. You can move the visitor into another package V that depends on A and B.

My choice would be to merge the packages, or not use the visitor pattern. Otherwise whenever someone creates a new subclass of A, they will have to update the visitor in some other source file far, far away. It is all too likely that someone will forget to do that.

share|improve this answer
add comment

You can use something like:

public static class X {
    public void accept(Visitor v){
        if (v instanceof XVisitor){
            ((XVisitor)v).visitX(this);
        }
    }
}
public static interface Acceptor{
    public void accept(Visitor v);        
}
public static interface Visitor{
}
public static interface XVisitor extends Visitor {
    public void visitX(X x);
}

This way you get rid of cyclic dependency, but introduce using instanceof. But you don't have chain if ifs using instanceof and you have instanceof "uglyness" contained in few classes, but you can add both visitors and acceptors (or visitees?)

PS: in my example, you can get rid if Visitor interface, but for eas of thinking I put it there. And you could make accept and visit methods return something, but that's outside of scope of this idea. PS2: This idea is not mine, but I don't remeber where I saw it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.