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.
9
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);
}
}
2
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.
1
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.
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.
Using the acyclic visitor pattern from Robert C. Martin, which completes the approach from the selected answer. Here’s the link to his article presenting it, and below a screenshot of the solution in case the link breaks.
The degenerate Visitor class breaks the cycle.